An erratum in the HAFDBS implementation in AmpereOne was addressed by
clearing the feature in the ID register, with the expectation that
software would not attempt to use the corresponding controls in TCR_EL1.
The architecture, on the other hand, takes a much more pedantic stance
on the subject, requiring the TCR bits behave as RES0.
Take an extremely conservative stance on the issue and leverage the
precise write trap afforded by FGT. Handle guest writes by clearing HA
and HD before writing the intended value to the EL1 register alias.
Link: https://lore.kernel.org/r/20230609220104.1836988-4-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
A subsequent change will need to flip more trap bits in HFGWTR_EL2. Make
room for this by factoring out the programming of the HFGxTR registers
into helpers and using locals to build the set/clear masks.
Link: https://lore.kernel.org/r/20230609220104.1836988-3-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
AmpereOne has an erratum in its implementation of FEAT_HAFDBS that
required disabling the feature on the design. This was done by reporting
the feature as not implemented in the ID register, although the
corresponding control bits were not actually RES0. This does not align
well with the requirements of the architecture, which mandates these
bits be RES0 if HAFDBS isn't implemented.
The kernel's use of stage-1 is unaffected, as the HA and HD bits are
only set if HAFDBS is detected in the ID register. KVM, on the other
hand, relies on the RES0 behavior at stage-2 to use the same value for
VTCR_EL2 on any cpu in the system. Mitigate the non-RES0 behavior by
leaving VTCR_EL2.HA clear on affected systems.
Cc: stable@vger.kernel.org
Cc: D Scott Phillips <scott@os.amperecomputing.com>
Cc: Darren Hart <darren@os.amperecomputing.com>
Acked-by: D Scott Phillips <scott@os.amperecomputing.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230609220104.1836988-2-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Both create_mapping_noalloc() and update_mapping_prot() sanity-check
their 'virt' parameter, but the check itself doesn't make much sense.
The condition used today appears to be a historical accident.
The sanity-check condition:
if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
[ ... warning here ... ]
return;
}
... can only be true for the KASAN shadow region or the module region,
and there's no reason to exclude these specifically for creating and
updateing mappings.
When arm64 support was first upstreamed in commit:
c1cc155261 ("arm64: MMU initialisation")
... the condition was:
if (virt < VMALLOC_START) {
[ ... warning here ... ]
return;
}
At the time, VMALLOC_START was the lowest kernel address, and this was
checking whether 'virt' would be translated via TTBR1.
Subsequently in commit:
14c127c957 ("arm64: mm: Flip kernel VA space")
... the condition was changed to:
if ((virt >= VA_START) && (virt < VMALLOC_START)) {
[ ... warning here ... ]
return;
}
This appear to have been a thinko. The commit moved the linear map to
the bottom of the kernel address space, with VMALLOC_START being at the
halfway point. The old condition would warn for changes to the linear
map below this, and at the time VA_START was the end of the linear map.
Subsequently we cleaned up the naming of VA_START in commit:
77ad4ce693 ("arm64: memory: rename VA_START to PAGE_END")
... keeping the erroneous condition as:
if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
[ ... warning here ... ]
return;
}
Correct the condition to check against the start of the TTBR1 address
space, which is currently PAGE_OFFSET. This simplifies the logic, and
more clearly matches the "outside kernel range" message in the warning.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
At the time of authoring 7655abb953 ("arm64: mm: Move ASID from TTBR0
to TTBR1"), the Arm ARM did not specify any ordering guarantees for
direct writes to TTBR0_ELx and TTBR1_ELx and so an ISB was required
after each write to ensure TLBs would only be populated from the
expected (or reserved tables).
In a recent update to the Arm ARM, the requirements have been relaxed to
reflect the implementation of current CPUs and required implementation
of future CPUs to read (RDYDPX in D8.2.3 Translation table base address
register):
Direct writes to TTBR0_ELx and TTBR1_ELx occur in program order
relative to one another, without the need for explicit
synchronization. For any one translation, all indirect reads of
TTBR0_ELx and TTBR1_ELx that are made as part of the translation
observe only one point in that order of direct writes.
Remove the superfluous ISBs to optimize uaccess helpers and context
switch.
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Jamie Iles <quic_jiles@quicinc.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20230613141959.92697-1-quic_jiles@quicinc.com
[catalin.marinas@arm.com: rename __cpu_set_reserved_ttbr0 to ..._nosync]
[catalin.marinas@arm.com: move the cpu_set_reserved_ttbr0_nosync() call to cpu_do_switch_mm()]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
commit 'ebdcfc8c42c2 ("arm64: dts: adapt to LP855X bindings changes")'
is a Tegra change, but was accidentally merged in the Qualcomm tree. The
change is reverted to avoid rebasing a large number of other changes.
This reverts commit ebdcfc8c42.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Prepare for pinctrl-single yaml binding and unify pin group node names.
Let's standardize on pin group node naming ending in -pins. As we don't
necessarily have a SoC specific compatible property for pinctrl-single.
I'd rather not add a pattern match for pins somewhere in the name for all
the users.
Trying to add matches for pins-default will be futile as on the earlier
SoCs we've already seen names like pins-sleep, pins-idle, pins-off and so
on that would need to be matched.
And as the node is a pin group, let's prefer to use naming -pins rather
than -pin as more pins may need to be added to the pin group later on.
Signed-off-by: Tony Lindgren <tony@atomide.com>
[vigneshr@ti.com: Rebase onto latest ti/next and extend to new nodes]
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The phyCORE-AM62x [1] is a SoM (System on Module) featuring TI's AM62x SoC.
It can be used in combination with different carrier boards.
This module can come with different sizes and models for
DDR, eMMC, SPI NOR Flash and various SoCs from the AM62x family.
A development Kit, called phyBOARD-Lyra [2] is used as a carrier board
reference design around the AM62x SoM.
Supported features:
* Debug UART
* SPI NOR Flash
* eMMC
* 2x Ethernet
* Micro SD card
* I2C EEPROM
* I2C RTC
* GPIO Expander
* LEDs
* USB
For more details, see:
[1] Product page SoM: https://www.phytec.com/product/phycore-am62x
[2] Product page CB: https://www.phytec.com/product/phyboard-am62x
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230504140143.1425951-2-w.egorov@phytec.de
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
* kvm-arm64/misc:
: Miscellaneous updates
:
: - Avoid trapping CTR_EL0 on systems with FEAT_EVT, as the register is
: commonly read by userspace
:
: - Make use of FEAT_BTI at hyp stage-1, setting the Guard Page bit to 1
: for executable mappings
:
: - Use a separate set of pointer authentication keys for the hypervisor
: when running in protected mode (i.e. pKVM)
:
: - Plug a few holes in timer initialization where KVM fails to free the
: timer IRQ(s)
KVM: arm64: Use different pointer authentication keys for pKVM
KVM: arm64: timers: Fix resource leaks in kvm_timer_hyp_init()
KVM: arm64: Use BTI for nvhe
KVM: arm64: Relax trapping of CTR_EL0 when FEAT_EVT is available
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
* kvm-arm64/configurable-id-regs:
: Configurable ID register infrastructure, courtesy of Jing Zhang
:
: Create generalized infrastructure for allowing userspace to select the
: supported feature set for a VM, so long as the feature set is a subset
: of what hardware + KVM allows. This does not add any new features that
: are user-configurable, and instead focuses on the necessary refactoring
: to enable future work.
:
: As a consequence of the series, feature asymmetry is now deliberately
: disallowed for KVM. It is unlikely that VMMs ever configured VMs with
: asymmetry, nor does it align with the kernel's overall stance that
: features must be uniform across all cores in the system.
:
: Furthermore, KVM incorrectly advertised an IMP_DEF PMU to guests for
: some time. Migrations from affected kernels was supported by explicitly
: allowing such an ID register value from userspace, and forwarding that
: along to the guest. KVM now allows an IMP_DEF PMU version to be restored
: through the ID register interface, but reinterprets the user value as
: not implemented (0).
KVM: arm64: Rip out the vestiges of the 'old' ID register scheme
KVM: arm64: Handle ID register reads using the VM-wide values
KVM: arm64: Use generic sanitisation for ID_AA64PFR0_EL1
KVM: arm64: Use generic sanitisation for ID_(AA64)DFR0_EL1
KVM: arm64: Use arm64_ftr_bits to sanitise ID register writes
KVM: arm64: Save ID registers' sanitized value per guest
KVM: arm64: Reuse fields of sys_reg_desc for idreg
KVM: arm64: Rewrite IMPDEF PMU version as NI
KVM: arm64: Make vCPU feature flags consistent VM-wide
KVM: arm64: Relax invariance of KVM_ARM_VCPU_POWER_OFF
KVM: arm64: Separate out feature sanitisation and initialisation
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
* kvm-arm64/hvhe:
: Support for running split-hypervisor w/VHE, courtesy of Marc Zyngier
:
: From the cover letter:
:
: KVM (on ARMv8.0) and pKVM (on all revisions of the architecture) use
: the split hypervisor model that makes the EL2 code more or less
: standalone. In the later case, we totally ignore the VHE mode and
: stick with the good old v8.0 EL2 setup.
:
: We introduce a new "mode" for KVM called hVHE, in reference to the
: nVHE mode, and indicating that only the hypervisor is using VHE.
KVM: arm64: Fix hVHE init on CPUs where HCR_EL2.E2H is not RES1
arm64: Allow arm64_sw.hvhe on command line
KVM: arm64: Force HCR_E2H in guest context when ARM64_KVM_HVHE is set
KVM: arm64: Program the timer traps with VHE layout in hVHE mode
KVM: arm64: Rework CPTR_EL2 programming for HVHE configuration
KVM: arm64: Adjust EL2 stage-1 leaf AP bits when ARM64_KVM_HVHE is set
KVM: arm64: Disable TTBR1_EL2 when using ARM64_KVM_HVHE
KVM: arm64: Force HCR_EL2.E2H when ARM64_KVM_HVHE is set
KVM: arm64: Key use of VHE instructions in nVHE code off ARM64_KVM_HVHE
KVM: arm64: Remove alternatives from sysreg accessors in VHE hypervisor context
arm64: Use CPACR_EL1 format to set CPTR_EL2 when E2H is set
arm64: Allow EL1 physical timer access when running VHE
arm64: Don't enable VHE for the kernel if OVERRIDE_HVHE is set
arm64: Add KVM_HVHE capability and has_hvhe() predicate
arm64: Turn kaslr_feature_override into a generic SW feature override
arm64: Prevent the use of is_kernel_in_hyp_mode() in hypervisor code
KVM: arm64: Drop is_kernel_in_hyp_mode() from __invalidate_icache_guest_page()
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
* kvm-arm64/ffa-proxy:
: pKVM FF-A Proxy, courtesy Will Deacon and Andrew Walbran
:
: From the cover letter:
:
: pKVM's primary goal is to protect guest pages from a compromised host by
: enforcing access control restrictions using stage-2 page-tables. Sadly,
: this cannot prevent TrustZone from accessing non-secure memory, and a
: compromised host could, for example, perform a 'confused deputy' attack
: by asking TrustZone to use pages that have been donated to protected
: guests. This would effectively allow the host to have TrustZone
: exfiltrate guest secrets on its behalf, hence breaking the isolation
: that pKVM intends to provide.
:
: This series addresses this problem by providing pKVM with the ability to
: monitor SMCs following the Arm FF-A protocol. FF-A provides (among other
: things) a set of memory management APIs allowing the Normal World to
: share, donate or lend pages with Secure. By monitoring these SMCs, pKVM
: can ensure that the pages that are shared, lent or donated to Secure by
: the host kernel are only pages that it owns.
KVM: arm64: pkvm: Add support for fragmented FF-A descriptors
KVM: arm64: Handle FFA_FEATURES call from the host
KVM: arm64: Handle FFA_MEM_LEND calls from the host
KVM: arm64: Handle FFA_MEM_RECLAIM calls from the host
KVM: arm64: Handle FFA_MEM_SHARE calls from the host
KVM: arm64: Add FF-A helpers to share/unshare memory with secure world
KVM: arm64: Handle FFA_RXTX_MAP and FFA_RXTX_UNMAP calls from the host
KVM: arm64: Allocate pages for hypervisor FF-A mailboxes
KVM: arm64: Probe FF-A version and host/hyp partition ID during init
KVM: arm64: Block unsafe FF-A calls from the host
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
* kvm-arm64/eager-page-splitting:
: Eager Page Splitting, courtesy of Ricardo Koller.
:
: Dirty logging performance is dominated by the cost of splitting
: hugepages to PTE granularity. On systems that mere mortals can get their
: hands on, each fault incurs the cost of a full break-before-make
: pattern, wherein the broadcast invalidation and ensuing serialization
: significantly increases fault latency.
:
: The goal of eager page splitting is to move the cost of hugepage
: splitting out of the stage-2 fault path and instead into the ioctls
: responsible for managing the dirty log:
:
: - If manual protection is enabled for the VM, hugepage splitting
: happens in the KVM_CLEAR_DIRTY_LOG ioctl. This is desirable as it
: provides userspace granular control over hugepage splitting.
:
: - Otherwise, if userspace relies on the legacy dirty log behavior
: (clear on collection), hugepage splitting is done at the moment dirty
: logging is enabled for a particular memslot.
:
: Support for eager page splitting requires explicit opt-in from
: userspace, which is realized through the
: KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE capability.
arm64: kvm: avoid overflow in integer division
KVM: arm64: Use local TLBI on permission relaxation
KVM: arm64: Split huge pages during KVM_CLEAR_DIRTY_LOG
KVM: arm64: Open-code kvm_mmu_write_protect_pt_masked()
KVM: arm64: Split huge pages when dirty logging is enabled
KVM: arm64: Add kvm_uninit_stage2_mmu()
KVM: arm64: Refactor kvm_arch_commit_memory_region()
KVM: arm64: Add kvm_pgtable_stage2_split()
KVM: arm64: Add KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE
KVM: arm64: Export kvm_are_all_memslots_empty()
KVM: arm64: Add helper for creating unlinked stage2 subtrees
KVM: arm64: Add KVM_PGTABLE_WALK flags for skipping CMOs and BBM TLBIs
KVM: arm64: Rename free_removed to free_unlinked
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
There's no longer a need for the baggage of the old scheme for handling
configurable ID register fields. Rip it all out in favor of the
generalized infrastructure.
Link: https://lore.kernel.org/r/20230609190054.1542113-12-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Everything is in place now to use the generic ID register
infrastructure. Use the VM-wide values to service ID register reads.
The ID registers are invariant after the VM has started, so there is no
need for locking in that case. This is rather desirable for VM live
migration, as the needless lock contention could prolong the VM blackout
period.
Link: https://lore.kernel.org/r/20230609190054.1542113-11-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
KVM allows userspace to write to the CSV2 and CSV3 fields of
ID_AA64PFR0_EL1 so long as it doesn't over-promise on the
Spectre/Meltdown mitigation state. Switch over to the new way of the
world for screening user writes. Leave the old plumbing in place until
we actually start handling ID register reads from the VM-wide values.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Link: https://lore.kernel.org/r/20230609190054.1542113-10-oliver.upton@linux.dev
[Oliver: split from monster patch, added commit description]
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
KVM allows userspace to specify a PMU version for the guest by writing
to the corresponding ID registers. Currently the validation of these
writes is done manuallly, but there's no reason we can't switch over to
the generic sanitisation infrastructure.
Start screening user writes through arm64_check_features() to prevent
userspace from over-promising in terms of vPMU support. Leave the old
masking in place for now, as we aren't completely ready to serve reads
from the VM-wide values.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Link: https://lore.kernel.org/r/20230609190054.1542113-9-oliver.upton@linux.dev
[Oliver: split off from monster patch, cleaned up handling of NI vPMU
values, wrote commit description]
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Rather than reinventing the wheel in KVM to do ID register sanitisation
we can rely on the work already done in the core kernel. Implement a
generalized sanitisation of ID registers based on the combination of the
arm64_ftr_bits definitions from the core kernel and (optionally) a set
of KVM-specific overrides.
This all amounts to absolutely nothing for now, but will be used in
subsequent changes to realize user-configurable ID registers.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Link: https://lore.kernel.org/r/20230609190054.1542113-8-oliver.upton@linux.dev
[Oliver: split off from monster patch, rewrote commit description,
reworked RAZ handling, return EINVAL to userspace]
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Initialize the default ID register values upon the first call to
KVM_ARM_VCPU_INIT. The vCPU feature flags are finalized at that point,
so it is possible to determine the maximum feature set supported by a
particular VM configuration. Do nothing with these values for now, as we
need to rework the plumbing of what's already writable to be compatible
with the generic infrastructure.
Co-developed-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Link: https://lore.kernel.org/r/20230609190054.1542113-7-oliver.upton@linux.dev
[Oliver: Hoist everything into KVM_ARM_VCPU_INIT time, so the features
are final]
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The bootrom burned into the MT7986 SoC will try multiple locations on
the SPI-NAND flash to load bl2 in case the bl2 image located at the the
previously attempted offset is corrupt.
Use 0x100000 instead of 0x80000 as partition size for bl2 on SPI-NAND,
allowing for up to four redundant copies of bl2 (typically sized a
bit less than 0x40000).
Fixes: 8e01fb15b8 ("arm64: dts: mt7986: add Bananapi R3")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/ZH9UGF99RgzrHZ88@makrotopia.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add the GPU's OPP table. This is from the downstream ChromeOS kernel,
adapted to the new upstream opp-supported-hw binning format. Also add
dynamic-power-coefficient for the GPU.
Also add label for mfg1 power domain. This is to be used at the board
level to add a regulator supply for the power domain.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230609072906.2784594-5-wenst@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
On the MT8186, the chip is binned for different GPU voltages at the
highest OPPs. The binning value is stored in the efuse.
Add the NVMEM cell, and tie it to the GPU.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230609072906.2784594-4-wenst@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This adds clocks, dynamic power coefficients, and OPP tables for the CPU
cores, so that everything required at the SoC level for CPU freqency and
voltage scaling is available.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230609072906.2784594-3-wenst@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add a device node for the CCI (cache coherent interconnect) and an OPP
table for it. The OPP table was taken from the downstream ChromeOS
kernel.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230609072906.2784594-2-wenst@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add pwm-fan and cooling-maps to BananaPi-R3 devicetree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230530201235.22330-5-linux@fw-web.de
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add thermal-zones to mt7986 devicetree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230530201235.22330-4-linux@fw-web.de
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add thermal related nodes to mt7986 devicetree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230530201235.22330-3-linux@fw-web.de
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
The capacity-dmips-mhz parameter was miscalculated: this SoC runs
the first (Cortex-A55) cluster at a maximum of 2000MHz and the
second (Cortex-A76) cluster at a maximum of 2200MHz.
In order to calculate the right capacity-dmips-mhz, the following
test was performed:
1. CPUFREQ governor was set to 'performance' on both clusters
2. Ran dhrystone with 500000000 iterations for 10 times on each cluster
3. Calculated the mean result for each cluster
4. Calculated DMIPS/MHz: dmips_mhz = dmips_per_second / cpu_mhz
5. Scaled results to 1024:
result_c0 = dmips_mhz_c0 / dmips_mhz_c1 * 1024
The mean results for this SoC are:
Cluster 0 (LITTLE): 12016411 Dhry/s
Cluster 1 (BIG): 31702034 Dhry/s
The calculated scaled results are:
Cluster 0: 426.953226899238 (rounded to 427)
Cluster 1: 1024
Fixes: 48489980e2 ("arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230602183515.3778780-1-nfraprado@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
In the series "Adjust the dma-ranges for MTK IOMMU", the mtk-iommu
driver was adapted to separate the iova range based on the larb used,
and a dma-ranges property was added to the soc node in the devicetree of
the affected SoCs allowing the whole 16GB iova range to be used. Except
that for mt8192, there was no patch adding dma-ranges.
Add the missing dma-ranges property to the soc node like was done for
mt8195 and mt8186. This fixes the usage of the vcodec, which would
otherwise trigger iommu faults.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230601203221.3675915-1-nfraprado@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add video-codec lat and core nodes for mt8192 SoC.
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230303013842.23259-4-allen-kh.cheng@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add the cpufreq nodes for MT8192 SoC.
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230317061944.15434-1-allen-kh.cheng@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Currently a specific panel number is used in the Elm DTSI, which is
corresponded to a 12" panel. However, according to the official Chrome
OS devices document, Elm refers to Acer Chromebook R13, which, as the
name specifies, uses a 13.3" panel, which comes with EDID information.
As the kernel currently prioritizes the hardcoded timing parameters
matched with the panel number compatible, a wrong timing will be applied
to the 13.3" panel on Acer Chromebook R13, which leads to blank display.
Because the Elm DTSI is shared with Hana board, and Hana corresponds to
multiple devices from 11" to 14", a certain panel model number shouldn't
be present, and driving the panel according to its EDID information is
necessary.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230526100801.16310-1-uwu@icenowy.me
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
To store uncompressed bl2 more space is required than partition is
actually defined.
There is currently no known usage of this reserved partition.
Openwrt uses same partition layout.
We added same change to u-boot with commit d7bb1099 [1].
[1] d7bb109900
Cc: stable@vger.kernel.org
Fixes: 8e01fb15b8 ("arm64: dts: mt7986: add Bananapi R3")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20230528113343.7649-1-linux@fw-web.de
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add "regulator-boot-on" to "panel_fixed_3v3" to save time on powering
the regulator during boot. Also add "off-on-delay-us" to the node to
make sure the regulator never violates the panel timing requirements.
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230417123956.926266-1-treapking@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
On CPUs where E2H is RES1, we very quickly set the scene for
running EL2 with a VHE configuration, as we do not have any other
choice.
However, CPUs that conform to the current writing of the architecture
start with E2H=0, and only later upgrade with E2H=1. This is all
good, but nothing there is actually reconfiguring EL2 to be able
to correctly run the kernel at EL1. Huhuh...
The "obvious" solution is not to just reinitialise the timer
controls like we do, but to really intitialise *everything*
unconditionally.
This requires a bit of surgery, and is a good opportunity to
remove the macro that messes with SPSR_EL2 in init_el2_state.
With that, hVHE now works correctly on my trusted A55 machine!
Reported-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230614155129.2697388-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Enable wakeup_i2c and use un-used pinmux. While at it, describe the
board detection eeprom present on the board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230601183151.1000157-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable wakeup_i2c and use un-used pinmux. While at it, describe the
board detection eeprom present on the board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602153554.1571128-7-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Define the wakeup uart pin-mux for completeness and add explicit
muxing for mcu_uart0. This allows the device tree usage in bootloader
and firmwares that can configure the same appropriately.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602153554.1571128-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Define the wakeup uart pin-mux for completeness and add explicit
muxing for mcu_uart0. This allows the device tree usage in bootloader
and firmwares that can configure the same appropriately.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602153554.1571128-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add pinmux required to bring out the i2c and gpios on 40-pin RPi
expansion header on the AM68 SK board.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602153554.1571128-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The WKUP_PADCONFIG register region in J721S2 has multiple non-addressable
regions, accordingly split the existing wkup_pmx region as follows to avoid
the non-addressable regions and include the rest of valid WKUP_PADCONFIG
registers. Also update references to old nodes with new ones.
wkup_pmx0 -> 13 pins (WKUP_PADCONFIG 0 - 12)
wkup_pmx1 -> 11 pins (WKUP_PADCONFIG 14 - 24)
wkup_pmx2 -> 72 pins (WKUP_PADCONFIG 26 - 97)
wkup_pmx3 -> 1 pin (WKUP_PADCONFIG 100)
Fixes: b8545f9d3a ("arm64: dts: ti: Add initial support for J721S2 SoC")
Cc: <stable@vger.kernel.org> # 6.3
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Signed-off-by: Thejasvi Konduru <t-konduru@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602153554.1571128-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Aiases are defined at board level, so dropping from soc level
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230611111140.3189111-7-u-kumar1@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
main_i2c0 pin mux was duplicated in som and common file.
So removing duplicated node from common file.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230611111140.3189111-4-u-kumar1@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are timer IO pads in the MCU domain, and in the MAIN domain. These
pads can be muxed for the related timers.
There are timer IO control registers for input and output. The registers
for CTRLMMR_TIMER*_CTRL and CTRLMMR_MCU_TIMER*_CTRL are used to control
the input. The registers for CTCTRLMMR_TIMERIO*_CTRL and
CTRLMMR_MCU_TIMERIO*_CTRL the output.
The multiplexing is documented in TRM "5.1.2.3.1.4 Timer IO Muxing Control
Registers" and "5.1.3.3.1.5 Timer IO Muxing Control Registers", and the
CASCADE_EN bit is documented in TRM "12.6.3.1 Timers Overview".
For chaining timers, the timer IO control registers also have a CASCADE_EN
input bit in the CTRLMMR_TIMER*_CTRL in the registers. The CASCADE_EN bit
muxes the previous timer output, or possibly and external TIMER_IO pad
source, to the input clock of the selected timer instance for odd numered
timers. For the even numbered timers, the CASCADE_EN bit does not do
anything. The timer cascade input routing options are shown in TRM
"Figure 12-3224. Timers Overview". For handling beyond multiplexing, the
driver support for timer cascading should be likely be handled via the
clock framework.
The MCU timer controls are also marked as reserved for
usage by the MCU firmware.
Cc: Nishanth Menon <nm@ti.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230611111140.3189111-3-u-kumar1@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are 20 general purpose timers on j721e that can be used for
things like PWM using pwm-omap-dmtimer driver. There are also
additional ten timers in the MCU domain which are meant for MCU
firmware usage and hence marked reserved by default.
The odd numbered timers have the option of being cascaded to even
timers to create a 64 bit non-atomic counter which is racy in simple
usage, hence the clock muxes are explicitly setup to individual 32 bit
counters driven off system crystal (HFOSC) as default.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230611111140.3189111-2-u-kumar1@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Define the aliases at the board level instead of using generic aliases
at SoC level.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230601183151.1000157-9-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Define the aliases at the board level instead of using generic aliases
at SoC level.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230601183151.1000157-8-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Define the wakeup uart pin-mux for completeness. This allows the
device tree usage in bootloader and firmwares that can configure the
same appropriately.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230601183151.1000157-7-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable wakeup_i2c and use un-used pinmux. While at it, describe the
board detection eeprom present on the board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230601183151.1000157-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Explicitly define the pinmux rather than depend on bootloader configured
pinmux for the platform.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230601183151.1000157-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable wakeup_i2c and use un-used pinmux. While at it, describe the
board detection eeprom present on the board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230601183151.1000157-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Using a phandle makes it clear which UART we are choosing without needing
to resolve through an alias first.
Especially useful for boards like the TI J721s2-EVM where the alias is
"serial2" but it actually resolves to the 8th UART instance(main_uart8).
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230601184933.358731-2-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
As the binding for "current-speed" states, this should only be used
when the baud rate of an attached device cannot be detected. This is
the case for our attached on-board USB-to-UART converter used for
early kernel console. For all other unconnected/disabled ports this
can be configured in userspace later, DT is not the place for device
configuration, especially when there are already standard ways to
set serial baud in userspace.
Remove setting baud for all disabled serial ports and move setting
it for the couple enabled ports down into the board files.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230601184933.358731-1-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable wakeup_i2c and use un-used pinmux. While at it, describe the
board detection eeprom present on the board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602214937.2349545-8-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add wakeup and MCU uart. This allows the device tree usage in
bootloader and firmwares that can configure the same appropriately.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602214937.2349545-7-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
main_i2c0 is aliased as i2c0 which creates a problem for u-boot R5
SPL attempting to reuse the same definition in the common board
detection logic as it looks for the first i2c instance as the bus on
which to detect the eeprom to understand the board variant involved.
Switch main_i2c0 to i2c3 alias allowing us to introduce wkup_i2c0
and potentially space for mcu_i2c instances in the gap for follow on
patches.
Fixes: 635fb18ba0 ("arch: arm64: dts: Add support for AM69 Starter Kit")
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602214937.2349545-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable wakeup_i2c and use un-used pinmux. While at it, describe the
board detection eeprom present on the board.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602214937.2349545-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add wakeup and MCU uart. This allows the device tree usage in
bootloader and firmwares that can configure the same appropriately.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602214937.2349545-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
main_i2c0 is aliased as i2c0 which creates a problem for u-boot R5
SPL attempting to reuse the same definition in the common board
detection logic as it looks for the first i2c instance as the bus on
which to detect the eeprom to understand the board variant involved.
Switch main_i2c0 to i2c3 alias allowing us to introduce wkup_i2c0
and potentially space for mcu_i2c instances in the gap for follow on
patches.
Fixes: e20a06aca5 ("arm64: dts: ti: Add support for J784S4 EVM board")
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230602214937.2349545-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
MAIN_PLL0 has a flag set in DM (Device Manager) that removes it's
capability to re-initialise clock frequencies. CPTS and RGMII has
MAIN_PLL3 as their parent which does not have this flag. While RGMII
needs this reinitialisation to default frequency to be able to get
250MHz with its divider, CPTS can not get its required 200MHz with its
divider. Thus, move CPTS clock parent on J721S2 from MAIN_PLL3_HSDIV1 to
MAIN_PLL0_HSDIV6.
(Note: even GTC will be moved from MAIN_PLL3 to MAIN_PLL0 in U-Boot side
for the same reason)
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Link: https://lore.kernel.org/r/20230605110443.84568-1-n-francis@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-15-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-14-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-13-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-12-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-11-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-10-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle
and cell arguments easier to catch. Fix the outliers to be consistent
with the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-9-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle
and cell arguments easier to catch. Fix the outliers to be consistent
with the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-8-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle
and cell arguments easier to catch. Fix the outliers to be consistent
with the rest of the usage.
Cc: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-7-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Cc: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Move the eeprom WP GPIO mux configuration to be part of the eeprom node
instead of the I2C node.
Cc: Robert Nelson <robertcnelson@gmail.com>
Suggested-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Move the GPIO mux configuration needed for camera module to work to the
GPIO node instead of the I2C node.
Camera nodes are maintained as overlay files, but the common mux is
always needed to ensure that camera probes fine and ensuring the mux
is configured as part of the GPIO module allows for the multiple
overlay files to be simpler.
Cc: Robert Nelson <robertcnelson@gmail.com>
Suggested-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
When referring to array of phandles, using <> to separate the array
entries is better notation as it makes potential errors with phandle and
cell arguments easier to catch. Fix the outliers to be consistent with
the rest of the usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230606182220.3661956-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are timer IO pads in the MCU domain, and in the MAIN domain.
These pads can be muxed for the related timers.
The details of the multiplexing can be found in the register
documentation and Technical Reference Manual[1].
These are similar to J721e/J7200, but have different mux capabilities.
[1] http://www.ti.com/lit/zip/spruj52
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230531213215.602395-7-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are 20 general purpose timers on j784s4 that can be used for
things like PWM using pwm-omap-dmtimer driver. There are also
additional ten timers in the MCU domain which are meant for MCU
firmware usage and hence marked reserved by default.
Though the count is similar to J721e/J7200/j721s2, the device IDs
and clocks used in j784s4 are different with the option of certain
clocks having options of additional clock muxes. Since there is very
minimal reuse, it is cleaner to integrate as part of SoC files itself.
The defaults are configured for clocking the timers from system
clock(HFOSC0).
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230531213215.602395-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are timer IO pads in the MCU domain, and in the MAIN domain. These
pads can be muxed for the related timers.
The details of the multiplexing can be found in the register
documentation and Technical Reference Manual[1].
These are similar to J721e/J7200, but have different mux capabilities.
[1] https://www.ti.com/lit/zip/spruj28
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230531213215.602395-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are 20 general purpose timers on j721s2 that can be used for
things like PWM using pwm-omap-dmtimer driver. There are also
additional ten timers in the MCU domain which are meant for MCU
firmware usage and hence marked reserved by default.
Though the count is similar to J721e/J7200, the device IDs and clocks
used in j721s2 are different with the option of certain clocks having
options of additional clock muxes. Since there is very minimal reuse,
it is cleaner to integrate as part of SoC files itself. The defaults
are configured for clocking the timers from system clock(HFOSC0).
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230531213215.602395-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are timer IO pads in the MCU domain, and in the MAIN domain. These
pads can be muxed for the related timers.
There are timer IO control registers for input and output. The registers
for CTRLMMR_TIMER*_CTRL and CTRLMMR_MCU_TIMER*_CTRL are used to control
the input. The registers for CTCTRLMMR_TIMERIO*_CTRL and
CTRLMMR_MCU_TIMERIO*_CTRL the output.
The multiplexing is documented in Technical Reference Manual[1] under
"Timer IO Muxing Control Registers" and "Timer IO Muxing Control
Registers", and the "Timers Overview" chapters.
We do not expose the cascade_en bit due to the racy usage of
independent 32 bit registers in-line with the timer instantiation in
the device tree. The MCU timer controls are also marked as reserved for
usage by the MCU firmware.
[1] http://www.ti.com/lit/pdf/spruil1
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230531213215.602395-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
There are 20 general purpose timers on j721e that can be used for
things like PWM using pwm-omap-dmtimer driver. There are also
additional ten timers in the MCU domain which are meant for MCU
firmware usage and hence marked reserved by default.
The odd numbered timers have the option of being cascaded to even
timers to create a 64 bit non-atomic counter which is racy in simple
usage, hence the clock muxes are explicitly setup to individual 32 bit
counters driven off system crystal (HFOSC) as default.
These instantiation differs from J7200 and other SoCs with the device
IDs and clocks involved for muxing.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20230531213215.602395-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Security Management Subsystem(SMS) has it's own unique secure
proxy as part of Security Accelerator (SA3) module. This is used
for communicating with ROM and for special usecases such as HSM
operations. In addition MCU island has it's own secure proxy for
usecases involving the MCU micro controllers. These are in addition
to the one in the main domain DMSS subsystem that is used for general
purpose communication.
Describe the nodes for use with bootloaders and firmware that require
these communication paths which uses interrupts to corresponding micro
controller interrupt controller. Mark the node as disabled since these
instances do not have interrupts routed to the main processor by
default for a complete description of the node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230530165900.47502-8-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Security Management Subsystem(SMS) has it's own unique secure
proxy as part of Security Accelerator (SA3) module. This is used
for communicating with ROM and for special usecases such as HSM
operations. In addition MCU island has it's own secure proxy for
usecases involving the MCU micro controllers. These are in addition
to the one in the main domain DMSS subsystem that is used for general
purpose communication.
Describe the nodes for use with bootloaders and firmware that require
these communication paths which uses interrupts to corresponding micro
controller interrupt controller. Mark the node as disabled since these
instances do not have interrupts routed to the main processor by
default for a complete description of the node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230530165900.47502-7-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
MCU domain has it's own secure proxy for communicating with ROM and
for R5 micro controller firmware operations. This is in addition to
the one in the main domain NAVSS subsystem that is used for general
purpose communication.
Describe the node for use with bootloaders and firmware that require
this communication path which uses interrupts to corresponding micro
controller interrupt controller. Mark the node as disabled since this
instance does not have interrupts routed to the main processor by
default for a complete description of the node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230530165900.47502-6-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
MCU domain has it's own secure proxy for communicating with ROM and
for R5 micro controller firmware operations. This is in addition to
the one in the main domain NAVSS subsystem that is used for general
purpose communication.
Describe the node for use with bootloaders and firmware that require
this communication path which uses interrupts to corresponding micro
controller interrupt controller. Mark the node as disabled since this
instance does not have interrupts routed to the main processor by
default for a complete description of the node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20230530165900.47502-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
MCU domain has it's own secure proxy for communicating with ROM and
for R5 micro controller firmware operations. This is in addition to
the one in the main domain NAVSS subsystem that is used for general
purpose communication.
Describe the node for use with bootloaders and firmware that require
this communication path which uses interrupts to corresponding micro
controller interrupt controller. Mark the node as disabled since this
instance does not have interrupts routed to the main processor by
default for a complete description of the node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230530165900.47502-4-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Security Management Subsystem(SMS) has it's own unique secure
proxy as part of Security Accelerator (SA3) module. This is used
for communicating with ROM and for special usecases such as HSM
operations. This is in addition to the one in the main domain DMSS
subsystem that is used for general purpose communication.
Describe the node for use with bootloaders and firmware that require
this communication path which uses interrupts to corresponding micro
controller interrupt controller. Mark the node as disabled since this
instance does not have interrupts routed to the main processor by
default for a complete description of the node.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230530165900.47502-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Security Management Subsystem(SMS) has it's own unique secure
proxy as part of Security Accelerator (SA3) module. This is used
for communicating with ROM and for special usecases such as HSM
operations. This is in addition to the one in the main domain DMSS
subsystem that is used for general purpose communication.
Describe the node for use with bootloaders and firmware that require
this communication path which uses interrupts to corresponding micro
controller interrupt controller. Mark the node as disabled since this
instance does not have interrupts routed to the main processor by
default for a complete description of the node.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
[nm@ti.com: Update commit message, minor updates]
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230530165900.47502-2-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
ti,otap-del-sel has been deprecated in favor of ti,otap-del-sel-legacy.
Drop the duplicate and misleading ti,otap-del-sel property.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230607132043.3932726-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Describe OSPI flash partition information through device tree, this
helps to remove passing partition information through the mtdparts
commandline parameter which requires maintaining the partition
information in a string format. AM64 SK and EVM has a S28 64 MiB OSPI
flash with sector size of 256 KiB thus the size of the smallest partition
is chosen as 256 KiB, the partition names and offsets are chosen according
to the corresponding name and offsets in bootloader.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513141712.27346-6-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Describe OSPI flash partition information through device tree, this
helps to remove passing partition information through the mtdparts
commandline parameter which requires maintaining the partition
information in a string format. AM654 baseboard has a MT35XU512ABA
64 MiB OSPI flash with sector size of 128 KiB thus the size of the
smallest partition is chosen as 128 KiB, the partition names and
offsets are chosen according to the corresponding name and offsets
in bootloader.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513141712.27346-5-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Describe OSPI and Hyperflash partition information through device tree,
this helps to remove passing partition information through the mtdparts
commandline parameter which requires maintaining the partition information
in a string format. J7200 SoM has a S28 64 MiB OSPI flash with sector size
of 256 KiB thus the size of the smallest partition is chosen as 256 KiB,
the SoM also has a 64 MiB Hyperflash present on it, the partition names
and offsets are chosen according to the corresponding name and offsets
in bootloader.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513141712.27346-4-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Describe OSPI flash partition information through device tree, this
helps to remove passing partition information through the mtdparts
commandline parameter which requires maintaining the partition
information in a string format. J721E SK has a S28 64 MiB OSPI flash
with sector size of 256 KiB thus the size of the smallest partition is
chosen as 256 KiB, the partition names and offsets are chosen according
to the corresponding name and offsets in bootloader.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513141712.27346-3-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Describe OSPI and QSPI flash partition information through device tree,
this helps to remove passing partition information through the mtdparts
commandline parameter which requires maintaining the partition information
in a string format. J721E SoM has a MT35 64 MiB OSPI flash and MT25 64 MiB
QSPI flash both with sector size of 128 KiB thus the size of the smallest
partition is chosen as 128KiB, the partition names and offsets are chosen
according to the corresponding name and offsets in bootloader.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513141712.27346-2-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 has S28HS512T OSPI flash connected to OSPI0 and MT25QU512A QSPI
flash connected to OSPI1, enable support for the same. Also describe
the partition information according to the offsets in the bootloader.
Co-developed-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20230504080305.38986-3-a-nandan@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
TI K3 J784S4 has the Cadence OSPI controllers OSPI0 and OSPI1 on FSS
bus for interfacing with OSPI flashes. Add the nodes to allow using
SPI flashes.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20230504080305.38986-2-a-nandan@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
With commit 9f6ffd0da6 ("dt-bindings: leds: Convert PCA9532 to dtschema"),
we can now add the LED controller without introducing new dtbs_check warnings.
Add missing I2C LED controller.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20230505131012.2027309-1-w.egorov@phytec.de
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J721E common processor board has an onboard mux for selecting whether
the OSPI signals are externally routed to OSPI flash or Hyperflash. The
mux state signal input is tied to WKUP_GPIO0_8 and is used by bootloader
for enabling the corresponding node accordingly. Add pinmux for the same.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-5-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J7200 common processor board has an onboard mux for selecting whether
the OSPI signals are externally routed to OSPI flash or Hyperflash. The
mux state signal input is tied to WKUP_GPIO0_6 and is used by bootloader
for enabling the corresponding node accordingly. Add pinmux for the same.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-4-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J721E SoM has a HyperFlash and HyperRam connected to HyperBus memory
controller, add corresponding node, pinmux and partitions for the same.
HyperBus is muxed with OSPI and only one controller can be active at a
time, therefore keep HyperBus node disabled. Bootloader will detect the
external mux state through a wkup gpio and enable the node as required.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-3-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J721E has a Flash SubSystem that has one OSPI and one HyperBus with
muxed datapath and another independent OSPI. Add DT nodes for HyperBus
controller and keep it disabled and model the data path selection mux as a
reg-mux.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20230513123313.11462-2-vaishnav.a@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
MDIO nodes defined in the top-level J721e SoC dtsi files are incomplete
and will not be functional unless they are extended with a pinmux.
As the attached PHY is only known about at the board integration level,
these nodes should only be enabled when provided with this information.
Disable the MDIO nodes in the dtsi files and only enable the ones that
are actually pinned out on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-5-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Mailbox nodes defined in the top-level AM64x SoC dtsi files are incomplete
and may not be functional unless they are extended with a chosen interrupt
and connection to a remote processor.
As the remote processors depend on memory nodes which are only known at
the board integration level, these nodes should only be enabled when
provided with the above information.
Disable the Mailbox nodes in the dtsi files and only enable the ones that
are actually used on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-4-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
PCIe nodes defined in the top-level J721e SoC dtsi files are incomplete
and will not be functional unless they are extended with a SerDes PHY.
And usually only one of the two modes can be used at a time as they
share a SerDes link.
As the PHY and mode is only known at the board integration level, these
nodes should only be enabled when provided with this information.
Disable the PCIe nodes in the dtsi files and only enable the ones that
are actually pinned out on a given board.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-3-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
These nodes are example nodes for the PCIe controller in "endpoint" mode.
By default the controller is in "root complex" mode and there is already a
DT node for the same.
Examples should go in the bindings or other documentation.
Remove this node.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-2-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Mailbox nodes are now disabled by default. The BeagleBoard AI64 DT
addition went in at around the same time and must have missed that
change so the mailboxes are not re-enabled. Do that here.
Fixes: fae14a1cb8 ("arm64: dts: ti: Add k3-j721e-beagleboneai64")
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230515172137.474626-1-afd@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
eMMC tuning was incomplete earlier, so support for high speed modes was
kept disabled. Remove no-1-8-v property to enable support for high
speed modes for eMMC in J784S4 SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230502090814.144791-1-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 has two instances of 8 channel ADCs in MCU domain. Add pinmux
information for both ADC nodes.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230502081117.21431-3-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 has two instances of 8 channel ADCs in MCU domain. Add support
for both ADC nodes.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230502081117.21431-2-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The OLDI-LCD1EVM add on board has Rocktech RK101II01D-CT panel[1] with
integrated touch screen. The integrated touch screen is Goodix GT928.
This panel connects with AM65 GP-EVM[2].
Add DT nodes for these and connect the endpoint nodes with DSS.
[1]: Panel link
https://www.digimax.it/en/tft-lcd/20881-RK101II01D-CT
[2]: AM654 LCD EVM:
https://www.ti.com/tool/TMDSLCD1EVM
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
[abhatia1@ti.com: Make cosmetic and 6.4 kernel DTSO syntax changes]
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20230509102354.10116-2-a-bhatia1@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Update the delay values for various speed modes supported, based on
the revised august 2021 J721E Datasheet.
[1] - Table 7-77. MMC0 DLL Delay Mapping for All Timing Modes and
Table 7-86. MMC1/2 DLL Delay Mapping for All Timing Modes, in
https://www.ti.com/lit/ds/symlink/tda4vm.pdf,
(SPRSP36J – FEBRUARY 2019 – REVISED AUGUST 2021)
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Link: https://lore.kernel.org/r/20230424093827.1378602-1-b-kapoor@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Include documentation of the AMC package pin name as well to keep it
consistent with the rest of the pinctrl documentation.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230418213740.153519-5-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
wkup_uart and main_uart1 on this platform is used by tifs and DM
firmwares. Describe them for completeness including the pinmux.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230418213740.153519-3-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Looks like a couple of http:// links crept in. Use https instead.
While at it, drop unicode encoded character.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230417225450.1182047-1-nm@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Consolidate the arm64 decision making for the page protections used
for executable pages, used by both the trampoline code and the kernel
text mapping code.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/E1q9T3v-00EDmW-BH@rmk-PC.armlinux.org.uk
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The am62ax supports a single Voltage and Thermal Management (VTM) device
located in the wakeup domain with three associated temperature monitors
located in various hot spots of the die.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-4-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The am62x supports a single Voltage and Thermal Management (VTM) module
located in the wakeup domain with two associated temperature monitors
located in hot spots of the die.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-3-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The am64x supports a single VTM module which is located in the main
domain with two associated temperature monitors located at different hot
spots on the die.
Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-2-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add memory reservation for the zap-shader and enable the Adreno SMMU,
GPU clock controller, GMU and the GPU nodes for the SC8280XP CRD and the
Lenovo ThinkPad X13s.
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230614142204.2675653-3-quic_bjorande@quicinc.com
Oliver Upton