public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module
@ 2024-12-04 17:41 Andreas Kemnade
  2024-12-04 22:26 ` Roger Quadros
  2024-12-05 23:07 ` Kevin Hilman
  0 siblings, 2 replies; 3+ messages in thread
From: Andreas Kemnade @ 2024-12-04 17:41 UTC (permalink / raw)
  To: tony, robh, krzk+dt, conor+dt, andreas, hns, linux-omap,
	devicetree, linux-kernel, aaro.koskinen, khilman, rogerq
  Cc: stable

Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal,
disabling SPI leads to messages like when suspending:
Powerdomain (core_pwrdm) didn't enter target state 0
and according to /sys/kernel/debug/pm_debug/count off state is not
entered. That was not connected to SPI during the discussion
of disabling SPI. See:
https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/

The reason is that SPI is per default in slave mode. Linux driver
will turn it to master per default. It slave mode, the powerdomain seems to
be kept active if active chip select input is sensed.

Fix that by explicitly disabling the SPI3 pins which used to be muxed by
the bootloader since they are available on an optionally fitted header
which would require dtb overlays anyways.

Fixes: a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage")
CC: stable@vger.kernel.org
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
Changes in V3:
- use gpio mode instead of mode7 which is not safe mode in this special
  case

Changes in V2:
- instead of reenabling mcspi, do a fix more near the root of the
  problem

 arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
index 2ee3ddd640209..536070e80b2c6 100644
--- a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
@@ -446,6 +446,7 @@ &omap3_pmx_core2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <
 			&hsusb2_2_pins
+			&mcspi3hog_pins
 	>;
 
 	hsusb2_2_pins: hsusb2-2-pins {
@@ -459,6 +460,15 @@ OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d15.hsusb2_d
 		>;
 	};
 
+	mcspi3hog_pins: mcspi3hog-pins {
+		pinctrl-single,pins = <
+			OMAP3630_CORE2_IOPAD(0x25dc, PIN_OUTPUT_PULLDOWN | MUX_MODE4)	/* etk_d0 */
+			OMAP3630_CORE2_IOPAD(0x25de, PIN_OUTPUT_PULLDOWN | MUX_MODE4)	/* etk_d1 */
+			OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT_PULLDOWN | MUX_MODE4)	/* etk_d2 */
+			OMAP3630_CORE2_IOPAD(0x25e2, PIN_OUTPUT_PULLDOWN | MUX_MODE4)	/* etk_d3 */
+		>;
+	};
+
 	spi_gpio_pins: spi-gpio-pinmux-pins {
 		pinctrl-single,pins = <
 			OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* clk */
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module
  2024-12-04 17:41 [PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module Andreas Kemnade
@ 2024-12-04 22:26 ` Roger Quadros
  2024-12-05 23:07 ` Kevin Hilman
  1 sibling, 0 replies; 3+ messages in thread
From: Roger Quadros @ 2024-12-04 22:26 UTC (permalink / raw)
  To: Andreas Kemnade, tony, robh, krzk+dt, conor+dt, hns, linux-omap,
	devicetree, linux-kernel, aaro.koskinen, khilman
  Cc: stable



On 04/12/2024 19:41, Andreas Kemnade wrote:
> Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal,
> disabling SPI leads to messages like when suspending:
> Powerdomain (core_pwrdm) didn't enter target state 0
> and according to /sys/kernel/debug/pm_debug/count off state is not
> entered. That was not connected to SPI during the discussion
> of disabling SPI. See:
> https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/
> 
> The reason is that SPI is per default in slave mode. Linux driver
> will turn it to master per default. It slave mode, the powerdomain seems to
> be kept active if active chip select input is sensed.
> 
> Fix that by explicitly disabling the SPI3 pins which used to be muxed by
> the bootloader since they are available on an optionally fitted header
> which would require dtb overlays anyways.
> 
> Fixes: a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage")
> CC: stable@vger.kernel.org
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>

Reviewed-by: Roger Quadros <rogerq@kernel.org>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module
  2024-12-04 17:41 [PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module Andreas Kemnade
  2024-12-04 22:26 ` Roger Quadros
@ 2024-12-05 23:07 ` Kevin Hilman
  1 sibling, 0 replies; 3+ messages in thread
From: Kevin Hilman @ 2024-12-05 23:07 UTC (permalink / raw)
  To: tony, robh, krzk+dt, conor+dt, hns, linux-omap, devicetree,
	linux-kernel, aaro.koskinen, rogerq, Andreas Kemnade
  Cc: stable


On Wed, 04 Dec 2024 18:41:52 +0100, Andreas Kemnade wrote:
> Despite CM_IDLEST1_CORE and CM_FCLKEN1_CORE behaving normal,
> disabling SPI leads to messages like when suspending:
> Powerdomain (core_pwrdm) didn't enter target state 0
> and according to /sys/kernel/debug/pm_debug/count off state is not
> entered. That was not connected to SPI during the discussion
> of disabling SPI. See:
> https://lore.kernel.org/linux-omap/20230122100852.32ae082c@aktux/
> 
> [...]

Applied, thanks!

[1/1] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module
      commit: 93dadbfbd19fa45405e7ef04014c100b4f7a94ca

Best regards,
-- 
Kevin Hilman <khilman@baylibre.com>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-12-05 23:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-04 17:41 [PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module Andreas Kemnade
2024-12-04 22:26 ` Roger Quadros
2024-12-05 23:07 ` Kevin Hilman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox