| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Just use "rtc" as the nodename to better match with the bindings.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230607132043.3932726-4-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>
|
|
s/mcan/can to stay in sync with bindings conventions.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230607132043.3932726-2-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 9f6ffd0da650 ("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: fae14a1cb8dd ("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>
|
|
Add board EEPROM support to device tree
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230418213740.153519-4-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>
|
|
Drop an extra EoL
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20230418213740.153519-2-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>
|
|
VTM stands for Voltage Thermal Management. Add the thermal zones.
Six sensors mapping to six thermal zones. Main0, Main1, Main2, Main3,
WKUP1 & WKUP2 domains respectively.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[bb@ti.com: rebased on v6.3-rc1]
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-8-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
VTM stands for Voltage Thermal Management. Add the thermal zones.
Three sensors mapping to 3 thermal zones. MCU, MPU & Main domains
respectively.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[bb@ti.com: rebased on v6.3-rc1]
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-7-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
VTM stands for Voltage Thermal Management. Add the thermal zones.
Five sensors mapping ton 5 thermal zones. WKUP, MPU, C7x, GPU & R5F
respectively.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[bb@ti.com: rebased on v6.3-rc1]
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-6-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
VTM stands for Voltage Thermal Management. Add the thermal zones.
Seven sensors mapping to seven thermal zones. Main0, Main1, Main2, Main3,
Main4, WKUP1 & WKUP2 domains respectively.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[bb@ti.com: rebased on v6.3-rc1]
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20230405215328.3755561-5-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.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
|
|
Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the
SC8280XP.
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-2-quic_bjorande@quicinc.com
|
|
Some of the regulators must be always-on to ensure correct operation of
the system, e.g. PM8916 L2 for the LPDDR RAM, L5 for most digital I/O
and L7 for the CPU PLL (strictly speaking the CPU PLL might only need
an active-only vote but this is not supported for regulators in
mainline currently).
The RPM firmware seems to enforce that internally, these supplies stay
on even if we vote for them to power off (and there is no other
processor running). This means it's pointless to keep sending
enable/disable requests because they will just be ignored.
Also, drivers are much more likely to get a wrong impression of the
regulator status, because regulator_is_enabled() will return false when
there are no users, even though the regulator is always on.
Describe this properly by marking the regulators as always-on.
The same changes was already made for MSM8916 in commit 8bbd35771f90
("arm64: dts: qcom: msm8916-pm8916: Mark always-on regulators").
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-8-a3c3ac833567@gerhold.net
|
|
Right now each MSM8939 device has a huge block of regulator constraints
with allowed voltages for each regulator. For lack of better
documentation these voltages are often copied as-is from the vendor
device tree, without much extra thought.
Unfortunately, the voltages in the vendor device trees are often
misleading or even wrong, e.g. because:
- There is a large voltage range allowed and the actual voltage is
only set somewhere hidden in some messy vendor driver. This is often
the case for pm8916_{l14,l15,l16} because they have a broad range of
1.8-3.3V by default.
- The voltage is actually wrong but thanks to the voltage constraints
in the RPM firmware it still ends up applying the correct voltage.
To have proper regulator constraints it is important to review them in
context of the usage. The current setup in the MSM8939 device trees
makes this quite hard because each device duplicates the standard
voltages for components of the SoC and mixes those with minor
device-specific additions and dummy voltages for completely unused
regulators.
The actual usage of the regulators for the SoC components is in
msm8939-pm8916.dtsi, so it can and should also define the related
voltage constraints. These are not board-specific but defined in the
MSM8939/PM8916 specification. There is no documentation available for
MSM8939 but in practice it's almost identical to MSM8916.
Note that this commit does not make any functional change. All used
regulators still have the same regulator constraints as before. Unused
regulators do not have regulator constraints anymore because most of
these were too broad or even entirely wrong. They should be added back
with proper voltage constraints when there is an actual usage.
The same changes were already made for MSM8916 in commit b0a8f16ae4a0
("arm64: dts: qcom: msm8916: Define regulator constraints next to usage").
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-7-a3c3ac833567@gerhold.net
|
|
Add the same comment to msm8939-pm8916.dtsi that was added for the
MSM8916 variant in commit f193264986b5 ("arm64: dts: qcom:
msm8916-pm8916: Clarify purpose").
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-6-a3c3ac833567@gerhold.net
|
|
The regulator constraints for the MSM8939 devices were originally taken
from Qualcomm's msm-3.10 vendor device tree (for lack of better
documentation). Unfortunately it turns out that Qualcomm's voltages are
slightly off as well and do not match the voltage constraints applied
by the RPM firmware.
This means that we sometimes request a specific voltage but the RPM
firmware actually applies a much lower or higher voltage. This is
particularly critical for pm8916_l11 which is used as SD card VMMC
regulator: The SD card can choose a voltage from the current range of
1.8 - 2.95V. If it chooses to run at 1.8V we pretend that this is fine
but the RPM firmware will still silently end up configuring 2.95V.
This can be easily reproduced with a multimeter or by checking the
SPMI hardware registers of the regulator.
Apply the same change as for MSM8916 in commit 355750828c55 ("arm64:
dts: qcom: msm8916: Fix regulator constraints") and make the voltages
match the actual "specified range" in the PM8916 Device Specification
which is enforced by the RPM firmware.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-5-a3c3ac833567@gerhold.net
|
|
The vendor kernel from Sony does not have regulator-always-on for
pm8916_l6, so we should be able to disable it when setting up the
display properly. Since sony-tulip does not have display set up
currently it should be fine to let the regulator disable until then.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-4-a3c3ac833567@gerhold.net
|
|
msm8939-sony-xperia-kanuti-tulip.dts has several regulator voltages
that do not quite seem to match what is used in the vendor kernel.
In particular:
- l10 is fixed at 2.8V [1, 2]
- l11/l12 are 2.95V max [1]
[1]: https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/arch/arm/boot/dts/qcom/msm8939-regulator.dtsi
[2]: https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/arch/arm/boot/dts/qcom/msm8939-kanuti_tulip.dtsi#L671C1-L673
Fixes: f1134f738fad ("arm64: dts: qcom: Add msm8939 Sony Xperia M4 Aqua")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-3-a3c3ac833567@gerhold.net
|
|
Update for recent changes to msm8916.dtsi in commit a5cf21b14666
("arm64: dts: qcom: msm8916: Disable audio codecs by default") and
make lpass_codec disabled by default for devices that are not using
the audio codec functionality inside MSM8939.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-2-a3c3ac833567@gerhold.net
|
|
Update for recent changes to pm8916.dtsi in commit 38218822a72f
("arm64: dts: qcom: pm8916: Move default regulator "-supply"s")
and add the now missing pm8916_codec supplies to msm8939-pm8916.dtsi
as well.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230530-msm8939-regulators-v1-1-a3c3ac833567@gerhold.net
|
