summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2025-05-06arm64: dts: qcom: qcs8300: Add cpufreq scaling nodeImran Shaik1-0/+30
Add cpufreq-hw node to support cpufreq scaling on QCS8300. Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250430-qcs8300-cpufreq-scaling-v2-1-ee41566b8c56@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: sda660-ifc6560: Fix dt-validate warningAlexey Minnekhanov1-0/+2
If you remove clocks property, you should remove clock-names, too. Fixes warning with dtbs check: 'clocks' is a dependency of 'clock-names' Fixes: 34279d6e3f32c ("arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support") Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250504115120.1432282-4-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: sdm660-lavender: Add missing USB phy supplyAlexey Minnekhanov1-0/+1
Fixes the following dtbs check error: phy@c012000: 'vdda-pll-supply' is a required property Fixes: e5d3e752b050e ("arm64: dts: qcom: sdm660-xiaomi-lavender: Add USB") Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250504115120.1432282-3-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: sdm630: Add modem metadata memAlexey Minnekhanov1-1/+7
Similarly to MSM8998, add and use modem metadata memory region. This does not seemingly affect device functionality. But it fixes DTBs check warning: remoteproc@4080000: memory-region: [[45], [46]] is too short Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250504115120.1432282-2-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: ipq6018: drop standalone 'smem' nodeGabor Juhos1-6/+3
Since commit b5af64fceb04 ("soc: qcom: smem: Support reserved-memory description") the SMEM device can be instantiated directly from a reserved-memory node. The 'smem' node is defined in this way for each modern IPQ SoCs except for IPQ6018. In order to make it inline with the others, move the 'compatible' and the 'hwlock' properties into the respective reserved-memory node, and drop the standalone 'smem' node. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250506-ipq6018-drop-smem-v1-1-af99d177be2f@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06KVM: arm64: Propagate FGT masks to the nVHE hypervisorMarc Zyngier3-0/+22
The nVHE hypervisor needs to have access to its own view of the FGT masks, which unfortunately results in a bit of data duplication. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Unconditionally configure fine-grain trapsMark Rutland1-24/+15
... otherwise we can inherit the host configuration if this differs from the KVM configuration. Signed-off-by: Mark Rutland <mark.rutland@arm.com> [maz: simplified a couple of things] Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Use computed masks as sanitisers for FGT registersMarc Zyngier1-6/+6
Now that we have computed RES0 bits, use them to sanitise the guest view of FGT registers. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Add description of FGT bits leading to EC!=0x18Marc Zyngier1-6/+30
The current FTP tables are only concerned with the bits generating ESR_ELx.EC==0x18. However, we want an exhaustive view of what KVM really knows about. So let's add another small table that provides that extra information. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Compute FGT masks from KVM's own FGT tablesMarc Zyngier2-0/+120
In the process of decoupling KVM's view of the FGT bits from the wider architectural state, use KVM's own FGT tables to build a synthetic view of what is actually known. This allows for some checking along the way. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Plug FEAT_GCS handlingMarc Zyngier2-0/+19
We don't seem to be handling the GCS-specific exception class. Handle it by delivering an UNDEF to the guest, and populate the relevant trap bits. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Don't treat HCRX_EL2 as a FGT registerMarc Zyngier1-6/+3
Treating HCRX_EL2 as yet another FGT register seems excessive, and gets in a way of further improvements. It is actually simpler to just be explicit about the masking, so just to that. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Restrict ACCDATA_EL1 undef to FEAT_LS64_ACCDATA being disabledMarc Zyngier1-1/+3
We currently unconditionally make ACCDATA_EL1 accesses UNDEF. As we are about to support it, restrict the UNDEF behaviour to cases where FEAT_LS64_ACCDATA is not exposed to the guest. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Handle trapping of FEAT_LS64* instructionsMarc Zyngier1-0/+56
We generally don't expect FEAT_LS64* instructions to trap, unless they are trapped by a guest hypervisor. Otherwise, this is just the guest playing tricks on us by using an instruction that isn't advertised, which we handle with a well deserved UNDEF. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Simplify handling of negative FGT bitsMarc Zyngier1-37/+12
check_fgt_bit() and triage_sysreg_trap() implement the same thing twice for no good reason. We have to lookup the FGT register twice, as we don't communicate it. Similarly, we extract the register value at the wrong spot. Reorganise the code in a more logical way so that things are done at the correct location, removing a lot of duplication. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Tighten handling of unknown FGT groupsMarc Zyngier1-2/+3
triage_sysreg_trap() assumes that it knows all the possible values for FGT groups, which won't be the case as we start adding more FGT registers (unless we add everything in one go, which is obviously undesirable). At the same time, it doesn't offer much in terms of debugging info when things go wrong. Turn the "__NR_FGT_GROUP_IDS__" case into a default, covering any unhandled value, and give the kernel hacker a bit of a clue about what's wrong (system register and full trap descriptor). Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: Add FEAT_FGT2 capabilityMarc Zyngier2-0/+8
As we will eventually have to context-switch the FEAT_FGT2 registers in KVM (something that has been completely ignored so far), add a new cap that we will be able to check for. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: Add syndrome information for trapped LD64B/ST64B{,V,V0}Marc Zyngier1-1/+7
Provide the architected EC and ISS values for all the FEAT_LS64* instructions. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: Remove duplicated sysreg encodingsMarc Zyngier1-11/+0
A bunch of sysregs are now generated from the sysreg file, so no need to carry separate definitions. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add system instructions trapped by HFGIRT2_EL2Marc Zyngier1-1/+4
Add the new CMOs trapped by HFGITR2_EL2. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add registers trapped by HDFG{R,W}TR2_EL2Marc Zyngier2-0/+353
Bulk addition of all the system registers trapped by HDFG{R,W}TR2_EL2. The descriptions are extracted from the BSD-licenced JSON file part of the 2025-03 drop from ARM. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add registers trapped by HFG{R,W}TR2_EL2Marc Zyngier1-0/+395
Bulk addition of all the system registers trapped by HFG{R,W}TR2_EL2. The descriptions are extracted from the BSD-licenced JSON file part of the 2025-03 drop from ARM. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update CPACR_EL1 descriptionMarc Zyngier1-1/+3
Add the couple of fields introduced with FEAT_NV2p1. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update TRBIDR_EL1 descriptionMarc Zyngier1-1/+6
Add the missing MPAM field. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update PMSIDR_EL1 descriptionMarc Zyngier1-2/+26
Add the missing SME, ALTCLK, FPF, EFT. CRR and FDS fields. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update ID_AA64PFR0_EL1 descriptionMarc Zyngier1-0/+1
Add the missing RASv2 description. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Replace HFGxTR_EL2 with HFG{R,W}TR_EL2Marc Zyngier9-193/+250
Treating HFGRTR_EL2 and HFGWTR_EL2 identically was a mistake. It makes things hard to reason about, has the potential to introduce bugs by giving a meaning to bits that are really reserved, and is in general a bad description of the architecture. Given that #defines are cheap, let's describe both registers as intended by the architecture, and repaint all the existing uses. Yes, this is painful. The registers themselves are generated from the JSON file in an automated way. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add layout for HCR_EL2Marc Zyngier2-61/+132
Add HCR_EL2 to the sysreg file, more or less directly generated from the JSON file. Since the generated names significantly differ from the existing naming, express the old names in terms of the new one. One day, we'll fix this mess, but I'm not in any hurry. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update ID_AA64MMFR4_EL1 descriptionMarc Zyngier1-3/+16
Resync the ID_AA64MMFR4_EL1 with the architectue description. This results in: - the new PoPS field - the new NV2P1 value for the NV_frac field - the new RMEGDI field - the new SRMASK field These fields have been generated from the reference JSON file. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add ID_AA64ISAR1_EL1.LS64 encoding for FEAT_LS64WBMarc Zyngier1-0/+1
The 2024 extensions are adding yet another variant of LS64 (aptly named FEAT_LS64WB) supporting LS64 accesses to write-back memory, as well as 32 byte single-copy atomic accesses using pairs of FP registers. Add the relevant encoding to ID_AA64ISAR1_EL1.LS64. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: dts: ti: k3-j721s2: Add GPU nodeMatt Coster1-0/+14
The J721S2 binding is based on the TI downstream binding in commit 54b0f2a00d92 ("arm64: dts: ti: k3-j721s2-main: add gpu node") from [1] but with updated compatible strings. The clock[2] and power[3] indices were verified from HTML docs, while the interrupt index comes from the TRM[4] (appendix "J721S2_Appendix_20241106_Public.xlsx", "Interrupts (inputs)", "GPU_BXS464_WRAP0_GPU_SS_0_OS_IRQ_OUT_0"). [1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel [2]: https://downloads.ti.com/tisci/esd/latest/5_soc_doc/j721s2/clocks.html [3]: https://downloads.ti.com/tisci/esd/latest/5_soc_doc/j721s2/devices.html [4]: https://www.ti.com/lit/zip/spruj28 (revision E) Reviewed-by: Randolph Sapp <rs@ti.com> Signed-off-by: Matt Coster <matt.coster@imgtec.com> Link: https://lore.kernel.org/r/20250428-bxs-4-64-dts-v4-2-eddafb4ae19f@imgtec.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62: New GPU binding detailsMatt Coster1-1/+3
Use the new compatible string and power domain name as introduced in commit 2c01d9099859 ("dt-bindings: gpu: img: Future-proofing enhancements"). Reviewed-by: Randolph Sapp <rs@ti.com> Signed-off-by: Matt Coster <matt.coster@imgtec.com> Link: https://lore.kernel.org/r/20250428-bxs-4-64-dts-v4-1-eddafb4ae19f@imgtec.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62-main: Add PRUSS-M nodeKishon Vijay Abraham I1-0/+90
Add the DT node for the PRUSS-M processor subsystem that is present on the K3 AM62x SoCs. The K3 AM62x family of SoC has one PRUSS-M instance and it has two Programmable Real-Time Units (PRU0 and PRU1). Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> [ Judith: Fix pruss_iclk id for pruss_coreclk_mux ] Signed-off-by: Judith Mendez <jm@ti.com> Tested-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Acked-by: Hari Nagalla <hnagalla@ti.com> Link: https://lore.kernel.org/r/20250430144343.972234-1-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am64: Reserve timers used by MCU FWHari Nagalla2-0/+40
AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses main domain timers as tick timers in these firmwares. Hence keep them as reserved in the Linux device tree. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-12-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62a7-sk: Reserve main_rti4 for C7x DSPHari Nagalla1-0/+5
The main rti4 watchdog timer is used by the C7x DSP, so reserve the timer in the linux device tree. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-11-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62a7-sk: Reserve main_timer2 for C7x DSPHari Nagalla1-0/+5
C7x DSP uses main_timer2, so mark it as reserved in linux DT. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-10-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processorsHari Nagalla1-5/+29
For each remote proc, reserve memory for IPC and bind the mailbox assignments. Two memory regions are reserved for each remote processor. The first region of 1MB of memory is used for Vring shared buffers and the second region is used as external memory to the remote processor for the resource table and for tracebuffer allocations. Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-9-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processorsDevarsh Thakkar1-6/+44
For each remote proc, reserve memory for IPC and bind the mailbox assignments. Two memory regions are reserved for each remote processor. The first region of 1MB of memory is used for Vring shared buffers and the second region is used as external memory to the remote processor for the resource table and for tracebuffer allocations. Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-8-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processorsDevarsh Thakkar1-6/+90
For each remote proc, reserve memory for IPC and bind the mailbox assignments. Two memory regions are reserved for each remote processor. The first region of 1MB of memory is used for Vring shared buffers and the second region is used as external memory to the remote processor for the resource table and for tracebuffer allocations. Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-7-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62a-main: Add C7xv device nodeJai Luthra1-0/+12
AM62A SoCs have a C7xv DSP subsystem with Analytics engine capability. This subsystem is intended for deep learning purposes. Define the device node for C7xv DSP. Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Tested-by: Daniel Schultz <d.schultz@phytec.de> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-6-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62a-wakeup: Add R5F device nodeDevarsh Thakkar1-0/+25
AM62A SoCs have a single R5F core in wakeup domain. This core is also used as a device manager for the SoC. Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Tested-by: Daniel Schultz <d.schultz@phytec.de> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-5-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62a-mcu: Add R5F remote proc nodeHari Nagalla1-0/+25
AM62A SoCs have a single R5F core in the MCU voltage domain. Add the R5FSS node with the child node for core0 in MCU voltage domain .dtsi file. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Tested-by: Daniel Schultz <d.schultz@phytec.de> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-4-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62-wakeup: Add wakeup R5F nodeHari Nagalla1-0/+25
AM62 SoC devices have a single core R5F processor in wakeup domain. The R5F processor in wakeup domain is used as a device manager for the SoC. Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Tested-by: Daniel Schultz <d.schultz@phytec.de> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-3-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass rangesJudith Mendez1-2/+6
Add cbass ranges for ATCM and BTCM on am62x device, without these, remoteproc driver fails to probe and attach to the DM r5 core and IPC communication is broken. Signed-off-by: Judith Mendez <jm@ti.com> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-2-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am625-beagleplay: Add required voltage supplies for ↵Rishikesh Donadkar1-0/+31
TEVI-OV5640 The device tree overlay for TEVI-OV5640 requires following voltage supplies: AVDD-supply: Analog voltage supply, 2.8 volts DOVDD-supply: Digital I/O voltage supply, 1.8 volts DVDD-supply: Digital core voltage supply, 3.3 volts Add them in the overlay. Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250506045225.1246873-3-r-donadkar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am625-beagleplay: Add required voltage supplies for OV5640Rishikesh Donadkar1-0/+31
The device tree overlay for OV5640 requires following voltage supplies: AVDD-supply: Analog voltage supply, 2.8 volts DOVDD-supply: Digital I/O voltage supply, 1.8 volts DVDD-supply: Digital core voltage supply, 1.5 volts Add them in the overlay. Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250506045225.1246873-2-r-donadkar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62x: Add required voltage supplies for TEVI-OV5640Rishikesh Donadkar1-0/+32
The device tree overlay for TEVI-OV5640 requires following voltage supplies as mentioned in the power section [1] AVDD-supply: Analog voltage supply, 2.8 volts DOVDD-supply: Digital I/O voltage supply, 1.8 volts DVDD-supply: Digital core voltage supply, 3.3 volts Add them in the DT overlay. Link: https://www.technexion.com/wp-content/uploads/2023/09/product-brief_tevi-ov5640.pdf Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250502162539.322091-5-r-donadkar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62x: Add required voltage supplies for OV5640Rishikesh Donadkar1-0/+32
The device tree overlay for OV5640 requires following voltage supplies as mentioned in the table 8-3 of the data-sheet [1]. AVDD-supply: Analog voltage supply, 2.8 volts DOVDD-supply: Digital I/O voltage supply, 1.8 volts DVDD-supply: Digital core voltage supply, 1.5 volts Add them in the overlay. Link: https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Link: https://lore.kernel.org/r/20250502162539.322091-4-r-donadkar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62x: Add required voltage supplies for IMX219Rishikesh Donadkar1-0/+31
The device tree overlay for the IMX219 sensor requires three voltage supplies to be defined: VANA (analog), VDIG (digital core), and VDDL (digital I/O) [1]. Add the corresponding voltage supply definitions in the overlay so that the same topography as dt-bindings is present in the DT overlay. Link: https://datasheets.raspberrypi.com/camera/camera-module-2-schematics.pdf [1] Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Link: https://lore.kernel.org/r/20250502162539.322091-3-r-donadkar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-05-06arm64: dts: ti: k3-am62p5-sk: Add regulator nodes for AM62PRishikesh Donadkar1-0/+22
Add regulator node for AM62P-SK VCC_3V3_MAIN is the output of LM5141-Q1, and it serves as an input to TPS22965DSGT which produces VCC_3V3_SYS [1] VCC_3V3_SYS servers as vin-supply for peripherals like CSI [1]. Link: https://www.ti.com/lit/zip/sprr487 [1] Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Link: https://lore.kernel.org/r/20250502162539.322091-2-r-donadkar@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 18:23:36 +0300