[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90d27f95-4747-4a67-96ee-4c865ded66eb@kernel.org>
Date: Thu, 5 Dec 2024 00:26:12 +0200
From: Roger Quadros <rogerq@...nel.org>
To: Andreas Kemnade <andreas@...nade.info>, tony@...mide.com,
robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, hns@...delico.com,
linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, aaro.koskinen@....fi, khilman@...libre.com
Cc: stable@...r.kernel.org
Subject: Re: [PATCH v3] ARM: dts: ti/omap: gta04: fix pm issues caused by spi
module
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@...r.kernel.org
> Signed-off-by: Andreas Kemnade <andreas@...nade.info>
Reviewed-by: Roger Quadros <rogerq@...nel.org>
Powered by blists - more mailing lists