- 29 Apr, 2024 19 commits
-
-
Stefan Eichenberger authored
Previously, we had the sleep-moci pin set to always on. However, the Dahlia carrier board supports disabling the sleep-moci when the system is suspended to power down peripherals that support it. This reduces overall power consumption. This commit adds support for this feature by disabling the reg_force_sleep_moci regulator and adding a new regulator for the USB hub that can be turned off when the system is suspended. Signed-off-by:
Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20240301084901.16656-3-eichest@gmail.comSigned-off-by:
Nishanth Menon <nm@ti.com>
-
Stefan Eichenberger authored
The Verdin family has a signal called sleep-moci which can be used to turn off peripherals on the carrier board when the SoM goes into suspend. So far we have hogged this signal, which means the peripherals are always on and it is not possible to add peripherals that depend on the sleep-moci to be on. With this change, we replace the hog with a regulator so that peripherals can add their own regulators that use the same gpio. Carrier boards that allow peripherals to be powered off in suspend can disable this regulator and implement their own regulator to control the sleep-moci. Signed-off-by:
-
Bhavya Kapoor authored
Enable the UHS modes for MMCSD in J722S by removing the no-1-8-v property. Signed-off-by:
Bhavya Kapoor <b-kapoor@ti.com> Reviewed-by:
Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20240422131840.34642-1-b-kapoor@ti.comSigned-off-by:
-
Dasnavis Sabiya authored
Remove sdhci-caps-mask to enable support for SDR104 speed mode for SD card and remove no-1-8-v property so that SD card can work in any UHS-1 high speed mode it can support. Fixes: 4664ebd8 ("arm64: dts: ti: Add initial support for J784S4 SoC") Signed-off-by:
Dasnavis Sabiya <sabiya.d@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
-
Bhavya Kapoor authored
According to TRM for J721S2, SDR104 speed mode is supported by the SoC but its capabilities were masked in device tree. Remove sdhci-caps-mask to enable support for SDR104 speed mode for SD card in J721S2 SoC. [+] Refer to : section 12.3.6.1.1 MMCSD Features, in J721S2 TRM - https://www.ti.com/lit/zip/spruj28 Fixes: b8545f9d ("arm64: dts: ti: Add initial support for J721S2 SoC") Signed-off-by:
-
Vignesh Raghavendra authored
Hook up required IO voltage regulators and drop no-1-8-v to support UHS modes on SD cards. Fixes: 5fc6b1b6 ("arm64: dts: ti: Introduce AM62A7 family of SoCs") Signed-off-by:
-
Judith Mendez authored
On AM65x platform, sdhci0 is for eMMC and sdhci1 is for SD. Remove the properties that are not applicable for each device. Fixes: eac99d38 ("arm64: dts: ti: k3-am654-main: Update otap-del-sel values") Fixes: d7600d07 ("arm64: dts: ti: k3-am65-main: Add support for sdhci1") Signed-off-by:
-
Judith Mendez authored
Update otap-del-sel properties as per datasheet [0]. Add missing clkbuf-sel and itap-del-sel values also as per datasheet [0]. Move clkbuf-sel and ti,trm-icp above the otap-del-sel properties so the sdhci nodes could be more uniform across platforms. [0] https://www.ti.com/lit/ds/symlink/am6548.pdf Fixes: eac99d38 ("arm64: dts: ti: k3-am654-main: Update otap-del-sel values") Fixes: d7600d07 ("arm64: dts: ti: k3-am65-main: Add support for sdhci1") Signed-off-by:
-
Nathan Morrisson authored
Add symbols when building the am625-phyboard-lyra-rdk DTB so overlays can be applied. Fixes: d8280f30 ("arm64: dts: ti: am62-phyboard-lyra: Add overlay to enable a GPIO fan") Signed-off-by:
Nathan Morrisson <nmorrisson@phytec.com> Reviewed-by:
Wadim Egorov <w.egorov@phytec.de> Link: https://lore.kernel.org/r/20240419193552.3090343-1-nmorrisson@phytec.comSigned-off-by:
-
Nathan Morrisson authored
The phyBOARD-Electra has a GPIO fan header. This overlay enables the fan header and sets the fan to turn on at 65C. Signed-off-by:
-
Brandon Brnich authored
This patch adds support for the Wave521cl on the AM62A-SK. Signed-off-by:
Brandon Brnich <b-brnich@ti.com> Reviewed-by:
Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20240415204659.798548-1-b-brnich@ti.comSigned-off-by:
-
Udit Kumar authored
Along fixing wkup UART RTS and TX pins as OUTPUT instead of INPUT updating J784S4 macro for pin mux instead of J721S2. Fixes: 45299dd1 ("arm64: dts: ti: k3-am69-sk: Add mcu and wakeup uarts") Fixes: 08ae12b6 ("arm64: dts: ti: k3-am69-sk: Enable wakeup_i2c0 and eeprom") Signed-off-by:
Udit Kumar <u-kumar1@ti.com> Reviewed-by:
-
Udit Kumar authored
Along fixing wkup UART TX pin as OUTPUT instead of INPUT, updating J784S4 macro for pin mux instead of J721S2. Fixes: 5dfbd1de ("arm64: dts: ti: k3-j784s4-evm: Enable wakeup_i2c0 and eeprom") Fixes: 6fa5d37a ("arm64: dts: ti: k3-j784s4-evm: Add mcu and wakeup uarts") Signed-off-by:
-
Roger Quadros authored
As per AM62A TRM [1] USB Link Power Management (LPM) feature is not supported. Disable it else it may cause enumeration failure on some devices. > 4.9.2.1 USB2SS Unsupported Features > The following features are not supported on this family of devices: > ... > - USB 2.0 ECN: Link Power Management (LPM) > ... [1] - https://www.ti.com/lit/pdf/spruj16Signed-off-by:
Roger Quadros <rogerq@kernel.org> Reviewed-by:
Ravi Gunasekaran <r-gunasekaran@ti.com> Link: https://lore.kernel.org/r/20240412-for-v6-10-am62-usb-typec-dt-v7-3-93b827adf97e@kernel.orgSigned-off-by:
-
Roger Quadros authored
There are two USB instances available on the am62p5 starter kit. Include and enable them for use on the board. USB LPM feature is kept disabled as it is not supported. Signed-off-by:
Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240412-for-v6-10-am62-usb-typec-dt-v7-2-93b827adf97e@kernel.orgSigned-off-by:
-
Roger Quadros authored
Exposing the entire CTRL_MMR space to syscon is not a good idea. Add sub-nodes for USB0_PHY_CTRL and USB1_PHY_CTRL and use them in the USB0/USB1 nodes. Signed-off-by:
-
Roger Quadros authored
Add PHY2 register space to USB wrapper node. This is required to deal with Errata i2409. Signed-off-by:
-
Jan Kiszka authored
Add the required nodes to enable ICSSG SR1.0 based prueth networking. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Diogo Ivo <diogo.ivo@siemens.com> Link: https://lore.kernel.org/r/20240409164314.157602-1-diogo.ivo@siemens.comSigned-off-by:
-
Garrett Giordano authored
The Audio Codec runs over the MCASP (Multichannel Audio Serial Port). Add pinmux for the Audio Reference Clock and MCASP2. Add DT nodes for Audio Codec, MCASP2, VCC 1v8 and VCC 3v3 regulators. Additionally, create a sound node that connects our sound card and the MCASP2. Signed-off-by:
Garrett Giordano <ggiordano@phytec.com> Reviewed-by:
-
- 25 Apr, 2024 6 commits
-
-
Andrew Davis authored
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by:
-
Andrew Davis authored
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by:
-
Andrew Davis authored
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by:
-
Andrew Davis authored
The FSS bus contains several register ranges. Using an empty ranges property works but causes a DT warning when we give this node an address. Fix this by explicitly defining the memory ranges in use. Signed-off-by:
-
Andrew Davis authored
These SerDes lane select muxes use bits from the same register as the SerDes clock select mux. Make the lane select mux a child of the SerDes control node. This removes one more requirement on scm-conf being a syscon node which will later be converted to fix a couple DTS check warnings. Signed-off-by:
-
Andrew Davis authored
This matches the binding for this register region which fixes a couple DTS check warnings. While here trim the leading 0s from the "reg" definition. Signed-off-by:
-
- 10 Apr, 2024 15 commits
-
-
Michael Walle authored
The J722S EVM has an on-board eMMC. Enable the SDHC interface for it. There is no pinmuxing required because the interface has dedicated pins. Signed-off-by:
Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20240403102302.3934932-1-mwalle@kernel.orgSigned-off-by:
-
Michael Walle authored
Device tree best practice is to disable any external interface in the dtsi and just enable them if needed in the device tree. Thus, disable the ethernet switch and its ports by default and just enable the ones used by the EVMs in their device trees. There is no functional change. Signed-off-by:
-
Nathan Morrisson authored
The phyBOARD-Electra has two TCAN1044VDD CAN transceivers which support CAN FD at 8 Mbps. Increase the maximum bitrate to 8 Mbps. Signed-off-by:
-
Nathan Morrisson authored
The phyBOARD-Lyra has one TCAN1044VDD CAN transceiver which supports CAN FD at 8 Mbps. Increase the maximum bitrate to 8 Mbps. Signed-off-by:
-
Francesco Dolcini authored
Add a GPIO hog to release PCIe reset on the carrier board, this is required to use M.2 or mPCIe cards. Verdin AM62 does not have any PCIe interface, however the Verdin family has PCIe and normally an M.2 or mPCIe slot is available in the carrier board that can be used with cards that use only the USB interface toward the host CPU, for example cellular network modem. Signed-off-by:
-
Francesco Dolcini authored
Generic GPIOs pinctrl nodes are not correct, gpio[1-4] are into the MCU domain and should be into &mcu_gpio0, gpio[5-8] were missing and are added in this commit. Fixes: 7698622f ("arm64: dts: ti: Add verdin am62 mallow board") Signed-off-by:
-
Andrew Davis authored
As described in the binding document for the "current-speed" property: "This should only be present in case a driver has no chance to know the baud rate of the slave device." This is not the case for the UART used in K3 devices, the current baud-rate can be calculated from the registers. Having this property has the effect of actually skipping the baud-rate setup in some drivers as it assumes it will already be set to this rate, which may not always be the case. It seems this property's purpose was mistaken as selecting the desired baud-rate, which it does not. It would have been wrong to select that here anyway as DT is not the place for configuration, especially when there are already more standard ways to set serial baud-rates. Signed-off-by:
-
Andrew Davis authored
As described in the binding document for the "current-speed" property: "This should only be present in case a driver has no chance to know the baud rate of the slave device." This is not the case for the UART used in K3 devices, the current baud-rate can be calculated from the registers. Having this property has the effect of actually skipping the baud-rate setup in some drivers as it assumes it will already be set to this rate, which may not always be the case. It seems this property's purpose was mistaken as selecting the desired baud-rate, which it does not. It would have been wrong to select that here anyway as DT is not the place for configuration, especially when there are already more standard ways to set serial baud-rates. Signed-off-by:
-
Andrew Davis authored
As described in the binding document for the "current-speed" property: "This should only be present in case a driver has no chance to know the baud rate of the slave device." This is not the case for the UART used in K3 devices, the current baud-rate can be calculated from the registers. Having this property has the effect of actually skipping the baud-rate setup in some drivers as it assumes it will already be set to this rate, which may not always be the case. It seems this property's purpose was mistaken as selecting the desired baud-rate, which it does not. It would have been wrong to select that here anyway as DT is not the place for configuration, especially when there are already more standard ways to set serial baud-rates. Signed-off-by:
-
Andrew Davis authored
As described in the binding document for the "current-speed" property: "This should only be present in case a driver has no chance to know the baud rate of the slave device." This is not the case for the UART used in K3 devices, the current baud-rate can be calculated from the registers. Having this property has the effect of actually skipping the baud-rate setup in some drivers as it assumes it will already be set to this rate, which may not always be the case. It seems this property's purpose was mistaken as selecting the desired baud-rate, which it does not. It would have been wrong to select that here anyway as DT is not the place for configuration, especially when there are already more standard ways to set serial baud-rates. Signed-off-by:
-
Andrew Davis authored
As described in the binding document for the "current-speed" property: "This should only be present in case a driver has no chance to know the baud rate of the slave device." This is not the case for the UART used in K3 devices, the current baud-rate can be calculated from the registers. Having this property has the effect of actually skipping the baud-rate setup in some drivers as it assumes it will already be set to this rate, which may not always be the case. It seems this property's purpose was mistaken as selecting the desired baud-rate, which it does not. It would have been wrong to select that here anyway as DT is not the place for configuration, especially when there are already more standard ways to set serial baud-rates. Signed-off-by:
-
Andrew Davis authored
As described in the binding document for the "current-speed" property: "This should only be present in case a driver has no chance to know the baud rate of the slave device." This is not the case for the UART used in K3 devices, the current baud-rate can be calculated from the registers. Having this property has the effect of actually skipping the baud-rate setup in some drivers as it assumes it will already be set to this rate, which may not always be the case. It seems this property's purpose was mistaken as selecting the desired baud-rate, which it does not. It would have been wrong to select that here anyway as DT is not the place for configuration, especially when there are already more standard ways to set serial baud-rates. Signed-off-by:
-
Markus Schneider-Pargmann authored
On am62-lp-sk the PMIC is not wired up to a power button. Remove this property. This fixes issues observed when entering a very deep sleep state that is not yet available upstream. Fixes: e6a51ffa ("arm64: ti: dts: Add support for AM62x LP SK") Signed-off-by:
Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/r/20240325152029.2933445-1-msp@baylibre.comSigned-off-by:
-
Sukrut Bellary authored
BeaglePlay SBC[1] has Texas Instrument's WL18xx WiFi chipset[2]. Currently, WLAN_EN is configured as regulator and regulator-always-on. However, the timing and wlan_en sequencing is not correctly modelled. This causes the sdio access to fail during runtime-pm power operations saving or during system suspend/resume/hibernation/freeze operations. This is because the WLAN_EN line is not deasserted to low '0' to power down the WiFi. So during restore, the WiFi driver tries to load the FW without following correct power sequence. WLAN_EN => '1'/assert (high) to power-up the chipset. Use mmc-pwrseq-simple to drive TI's WiFi (WL18xx) chipset enable 'WLAN_EN'. mmc-pwrseq-simple provides power sequence flexibility with support for post power-on and power-off delays. Typical log signature that indicates this bug is: wl1271_sdio mmc2:0001:2: sdio write failed (-110) Followed by possibly a kernel warning (depending on firmware present): WARNING: CPU: 1 PID: 45 at drivers/net/wireless/ti/wlcore/sdio.c:123 wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio] [1] https://www.beagleboard.org/boards/beagleplay [2] https://www.ti.com/lit/ds/symlink/wl1807mod.pdf Fixes: f5a731f0 ("arm64: dts: ti: Add k3-am625-beagleplay") Suggested-by:
Shengyu Qu <wiagn233@outlook.com> Signed-off-by:
Sukrut Bellary <sukrut.bellary@linux.com> Tested-by:
Robert Nelson <robertcnelson@gmail.com> Link: https://lore.kernel.org/r/20240325143511.2144768-1-nm@ti.comSigned-off-by:
-
Francesco Dolcini authored
TI SDHCI instance has a hardware debounce timer of 1 second as described in commit 7ca0f166 ("mmc: sdhci_am654: Add workaround for card detect debounce timer"), because of this the boot time increases of up to 1 second. Workaround the issue the same way that is done on arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts, using the SD1 CD as GPIO. Suggested-by:
João Paulo Silva Gonçalves <joao.goncalves@toradex.com> Closes: https://lore.kernel.org/all/0e81af80de3d55e72f79af83fa5db87f5c9938f8.camel@toradex.com/Signed-off-by:
-
