From: Andreas Kemnade <andreas@kemnade.info>
To: Tony Lindgren <tony@atomide.com>
Cc: Roger Quadros <rogerq@kernel.org>,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
hns@goldelico.com, linux-omap@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
aaro.koskinen@iki.fi, khilman@baylibre.com,
stable@vger.kernel.org
Subject: Re: [PATCH] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module
Date: Sun, 17 Nov 2024 22:22:37 +0100 [thread overview]
Message-ID: <20241117222237.01a9b0b5@akair> (raw)
In-Reply-To: <20241117111903.GB23206@atomide.com>
Hi Tony,
Am Sun, 17 Nov 2024 13:19:03 +0200
schrieb Tony Lindgren <tony@atomide.com>:
> * Andreas Kemnade <andreas@kemnade.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
next prev parent reply other threads:[~2024-11-17 21:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 22:51 [PATCH] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module Andreas Kemnade
2024-11-08 12:42 ` Roger Quadros
2024-11-08 17:41 ` Andreas Kemnade
2024-11-09 10:59 ` Roger Quadros
2024-11-11 15:09 ` Tony Lindgren
2024-11-11 18:31 ` Andreas Kemnade
2024-11-11 22:46 ` Andreas Kemnade
2024-11-16 20:27 ` Andreas Kemnade
2024-11-17 11:19 ` Tony Lindgren
2024-11-17 21:22 ` Andreas Kemnade [this message]
2024-11-18 13:08 ` Roger Quadros
2024-11-27 22:58 ` Andreas Kemnade
2024-11-28 12:39 ` Roger Quadros
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241117222237.01a9b0b5@akair \
--to=andreas@kemnade.info \
--cc=aaro.koskinen@iki.fi \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hns@goldelico.com \
--cc=khilman@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=robh@kernel.org \
--cc=rogerq@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox