| Age | Commit message (Collapse) | Author | Files | Lines |
|
The current number of KVM_IRQCHIP_NUM_PINS results in an order 3
allocation (32kb) for each guest start/restart which can result in OOM
killer activity when kernel memory is fragmented enough.
This fix reduces the number of iopins as s390 doesn't use them, hence
reducing the memory footprint.
|
|
if of_find_device_by_node() succeed, imx6q_suspend_init() doesn't have a
corresponding put_device(). Thus add a jump target to fix the exception
handling for this function implementation.
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
if of_find_device_by_node() succeed, imx_suspend_alloc_ocram() doesn't
have a corresponding put_device(). Thus add a jump target to fix the
exception handling for this function implementation.
Fixes: 1579c7b9fe01 ("ARM: imx53: Set DDR pins to high impedance when in suspend to RAM.")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add properties required for the bootloader to select
the correct bootloader blob. They have been removed from
the SoC device tree as they should be set on a per-device
basis.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-11-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add PSCI node to enable multi-processor startup.
Note that not every 8994 device firmware supports PSCI,
and even if, then it can only start the cores and not
shut them down.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-10-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add the CPU PMU to get perf support for hardware events.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-9-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add support for I2C and SPI buses to enable peripherals
such as touchscreens or sensors. Also add DMA nodes,
configuration and BLSP2 UART2 interface.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-8-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Enable support for SDHCI on msm8994-based devices.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-6-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add a proper CPU map to enable the use of all 8 cores.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-4-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add SPMI PMIC arbiter device to communicate with PMICs
attached to SPMI bus.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-3-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Following changes have been made:
- remove name, compatible and msm-id
- wrap clocks in clocks{}
- order nodes by name and by address
- clock_gcc -> gcc
- msmgpio -> tlmm
- qcom,smem -> smem
- remove unit-address from smem
- retire msm8994-pins.dtsi
- add some of the missing pins
- make comments C-style
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200623224813.297077-2-konradybcio@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
The IPCC hardware block provides a mechanism for triggering interrupts
between co-processors in recent Qualcomm SoCs. This is used as basis for
most form of communication between co-processors, so enable this
support.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200622222747.717306-7-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add remoteproc nodes for the audio, compute and sensor cores, define
glink for each one and enable them on the MTP with appropriate firmware
defined.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200622222747.717306-6-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
SMP2P is used for interrupting and being interrupted about remoteproc
state changes related to the audio, compute and sensor subsystems.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200622222747.717306-5-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add a node for the QMP AOSS.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200622222747.717306-4-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Add the IPCC node, used to send and receive IPC signals with
remoteprocs.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200622222747.717306-3-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
PM8150 ldo11 on the MTP is wired to VDD_SSC_CX and controlled in levels,
rather than as a regulator. As such it's available from the rpmhpd as
the SM8250_LCX power domain.
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Fixes: ec13d5c23a33 ("arm64: dts: qcom: sm8250-mtp: Add pm8150, pm8150l and pm8009")
Link: https://lore.kernel.org/r/20200622222747.717306-2-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
The SM8250 pinctrl driver provides pin configuration, pin muxing and
GPIO pin control for many pins on the SM8250 SoC.
Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200622220048.717073-1-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
|
|
Pull kvm fixes from Paolo Bonzini:
"All bugfixes except for a couple cleanup patches"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: VMX: Remove vcpu_vmx's defunct copy of host_pkru
KVM: x86: allow TSC to differ by NTP correction bounds without TSC scaling
KVM: X86: Fix MSR range of APIC registers in X2APIC mode
KVM: VMX: Stop context switching MSR_IA32_UMWAIT_CONTROL
KVM: nVMX: Plumb L2 GPA through to PML emulation
KVM: x86/mmu: Avoid mixing gpa_t with gfn_t in walk_addr_generic()
KVM: LAPIC: ensure APIC map is up to date on concurrent update requests
kvm: lapic: fix broken vcpu hotplug
Revert "KVM: VMX: Micro-optimize vmexit time when not exposing PMU"
KVM: VMX: Add helpers to identify interrupt type from intr_info
kvm/svm: disable KCSAN for svm_vcpu_run()
KVM: MIPS: Fix a build error for !CPU_LOONGSON64
|
|
The new json-schema based validation tools require SD/MMC controller
nodes to be named mmc. Rename all references to them.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The memory node requires a unit-address. For some boards the bootloader,
which is usually locked down, uses a hard-coded name for the memory node
without a unit-address, so we can't fix it on those boards.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The I/O and PLL supplies used for HDMI/DP have alternative names. Use
the names that are given in the hardware documentation for consistency.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The display controller's parent clock depends on the output that's
consuming data from the display controller, so it needs to be specified
as the parent of the corresponding output. The device tree bindings do
specify this, so just correct the existing device trees that get this
wrong.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Interrupt names are used to distinguish between the syncpoint and
general host1x interrupts. Make sure they are available in the DT so
that drivers can use them if necessary.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
While the host1x controller found on Tegra132 is the same as on Tegra124
it is good practice to also list a SoC-specific compatible string so any
SoC-specific quirks can be implemented in drivers if necessary.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
This interrupt can be used for the operating system to be interrupted
when certain events occur.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
On Tegra194, all clients of the memory subsystem can generally address
40 bits of system memory. However, bit 39 has special meaning and will
cause the memory controller to reorder sectors for block-linear buffer
formats. This is primarily useful for graphics-related devices.
Use of bit 39 must be controlled on a case-by-case basis. Buffers that
are used with bit 39 set by one device may be used with bit 39 cleared
by other devices.
Care must be taken to allocate buffers at addresses that do not require
bit 39 to be set. This is normally not an issue for system memory since
there are no Tegra-based systems with enough RAM to exhaust the 39-bit
physical address space. However, when a device is behind an IOMMU, such
as the ARM SMMU on Tegra194, the IOMMUs input address space can cause
IOVA allocations to happen in this region. This is for example the case
when an operating system implements a top-down allocation policy for IO
virtual addresses.
To account for this, describe the path that memory accesses take through
the system. Memory clients will send requests to the memory controller,
which forwards bits [38:0] of the address either to the external memory
controller or the SMMU, depending on the stream ID of the access. A good
way to describe this is using the interconnects bindings, see:
Documentation/devicetree/bindings/interconnect/interconnect.txt
The standard "dma-mem" path is used to describe the path towards system
memory via the memory controller. A dma-ranges property in the memory
controller's device tree node limits the range of DMA addresses that the
memory clients can use to bits [38:0], ensuring that bit 39 is not used.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v4:
- add additional entries for interconnect-names to match interconnects
- add EMC as destination for interconnect paths
Changes in v3:
- add missing interconnect properties for VIC
Changes in v2:
- use memory client IDs instead of stream IDs (Mikko Perttunen)
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The interface used by clients of the memory controller can be configured
in a number of different ways. Describe this path using the interconnect
bindings to enable the configuration of these parameters.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The SDHCI on Tegra210 is in fact not compatible with the one found on
Tegra124. Remove the extra compatible string to reflect that.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The SDHCI on Tegra194 is in fact not compatible with the one found on
Tegra186. Remove the extra compatible string to reflect that.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
It is customary to use angle brackets around each tuple in the
interrupts property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The standard mmio-sram bindings require the #address- and #size-cells
properties to be 1.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
PHYs need to have a #phy-cells property that defines how many cells are
required in their specifier. The standard Ethernet PHY doesn't require a
specifier, so set its #phy-cells to 0.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
PHYs need to have a #phy-cells property that defines how many cells are
required in their specifier. The standard Ethernet PHY doesn't require
a specifier, so set its #phy-cells to 0.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The display controller on Tegra114 is in fact not backwards-compatible
with the instantiation found on earlier SoCs. Drop the misleading
compatible string.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The instantiation of gr3d in Tegra114 is not backwards-compatible with
the version found on earlier chips. Remove the misleading compatible
string.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The instantiation of gr2d in Tegra114 is not backwards-compatible with
the version found on earlier chips. While the hardware IP is identical,
the compatible string also describes the integration of the IP, which
in the case of Tegra114 is slightly different in that it's part of the
HEG power partition, whereas it wasn't previously.
Drop the misleading compatible string so that drivers that support the
older integrations cannot match on it. Since they wouldn't be able to
control the power partition, such driver wouldn't be able to access any
of the registers of the IP.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The host1x device tree bindings require the clock- and interrupt-names
properties to be present, so add them where missing.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The host1x is not a simple bus, so drop the corresponding compatible
string.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The correct DSI/CSI supply property is called vdd-dsi-csi-supply, so use
that instead of the wrong vdd-supply property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The correct DSI/CSI supply property is called vdd-dsi-csi-supply, so use
that instead of the wrong vdd-supply property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
This property is not documented and will cause a validation failure.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The standard way to do this is to list out the regulators at the top
level. Adopt the standard way to fix validation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The standard way to do this is to list out the clocks at the top-level.
Adopt the standard way to fix validation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The Tegra SDHCI controller bindings state that the clock-names property
is required, so add the missing properties on Tegra114.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Print the Protected Processor Identification Number (PPIN) on processors
which support it.
[ bp: Massage. ]
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200623130059.8870-1-Smita.KoralahalliChannabasappa@amd.com
|
|
Versions of binutils prior to 2.33.1 don't understand the ELF notes that
are added by modern compilers to indicate the PAC and BTI options used
to build the code. This causes them to emit large numbers of warnings in
the form:
aarch64-linux-gnu-nm: warning: .tmp_vmlinux.kallsyms2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000
during the kernel build which is currently causing quite a bit of
disruption for automated build testing using clang.
In commit 15cd0e675f3f76b (arm64: Kconfig: ptrauth: Add binutils version
check to fix mismatch) we added a dependency on binutils to avoid this
issue when building with versions of GCC that emit the notes but did not
do so for clang as it was believed that the existing check for
.cfi_negate_ra_state was already requiring a new enough binutils. This
does not appear to be the case for some versions of binutils (eg, the
binutils in Debian 10) so instead refactor so we require a new enough
GNU binutils in all cases other than when we are using an old GCC
version that does not emit notes.
Other, more exotic, combinations of tools are possible such as using
clang, lld and gas together are possible and may have further problems
but rather than adding further version checks it looks like the most
robust thing will be to just test that we can build cleanly with the
configured tools but that will require more review and discussion so do
this for now to address the immediate problem disrupting build testing.
Reported-by: KernelCI <bot@kernelci.org>
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1054
Link: https://lore.kernel.org/r/20200619123550.48098-1-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The sigreturn code in the compat vDSO is unused. Remove it.
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The 32-bit sigreturn trampoline in the compat sigpage matches the binary
representation of the arch/arm/ sigpage exactly. This is important for
debuggers (e.g. GDB) and unwinders (e.g. libunwind) since they rely
on matching the instruction sequence in order to identify that they are
unwinding through a signal. The same cannot be said for the sigreturn
trampoline in the compat vDSO, which defeats the unwinder heuristics and
instead attempts to use unwind directives for the unwinding. This is in
contrast to arch/arm/, which never uses the vDSO for sigreturn.
Ensure compatibility with arch/arm/ and existing unwinders by always
using the sigpage for the sigreturn trampoline, regardless of the
presence of the compat vDSO.
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
In preparation for removing the signal trampoline from the compat vDSO,
allow the sigpage and the compat vDSO to co-exist.
For the moment the vDSO signal trampoline will still be used when built.
Subsequent patches will move to the sigpage consistently.
Acked-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|