[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241117222237.01a9b0b5@akair>
Date: Sun, 17 Nov 2024 22:22:37 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Tony Lindgren <tony@...mide.com>
Cc: Roger Quadros <rogerq@...nel.org>, 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, stable@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: ti/omap: gta04: fix pm issues caused by spi
module
Hi Tony,
Am Sun, 17 Nov 2024 13:19:03 +0200
schrieb Tony Lindgren <tony@...mide.com>:
> * Andreas Kemnade <andreas@...nade.info> [241116 20:27]:
> > mcspi is per default in slave mode, setting it to master solves issues.
> > And that happens when the driver is probed because its default is
> > master.
>
> OK interesting. Maybe set up a quirk function for it in ti-sysc.c.
> That way the mcspi will get idled also when set to status disabled
> and no mcspi driver is loaded.
>
First of all I think if status = "disabled" then no pins should be
muxed to mcspi. That prevents all mess.
So the only case left is spi enabled but no driver and CS input is
active. If we configure things as master via a quirk if the setup is
slave then switch something to output which should not be. We would have
some output againt output situation at least for a moment.
Maybe pinmuxing stuff in ti-sysc? Hmm, I am really unsure if it is
worth it.
Regarding the GTA04 case:
mcspi1,2 and 4 are not muxed, so that issue occurs only with mcspi3,
and therefore the most simple solution is to mux it to mode7 as sent
in the v2 which should also be suitable for -stable.
Regards,
Andreas
Powered by blists - more mailing lists