From: Kevin Hilman <khilman@kernel.org>
To: Thomas Richard <thomas.richard@bootlin.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: jirislaby@kernel.org, tony@atomide.com,
linux-serial@vger.kernel.org, gregory.clement@bootlin.com,
u-kumar1@ti.com, d-gole@ti.com, thomas.petazzoni@bootlin.com
Subject: Re: [PATCH] serial: 8250_omap: Set the console genpd always on if no console suspend
Date: Fri, 04 Oct 2024 12:23:31 -0700 [thread overview]
Message-ID: <7ha5fjlljg.fsf@baylibre.com> (raw)
In-Reply-To: <3fbe606e-fb0e-4ff8-924b-a8bbe046ee4b@bootlin.com>
Thomas Richard <thomas.richard@bootlin.com> writes:
[...]
> I finally found the culprit.
> Just adding the GENPD_FLAG_ACTIVE_WAKEUP flag by default caused the
> panic, even without the call of device_set_wakeup_path().
>
> With some debug, I found that the wakeup_path of all my uarts (even
> other uarts not used by the console) was set.
> So the corresponding power domains were not powered off [1].
> Consequently they are not powered on during the resume [2].
>
> But on my platform (J7200), the SoC is fully off during suspend-to-ram.
> Even if a power domain is not powered off by Linux, at the end all the
> SoC is off.
> And if Linux doesn't power off a power domain, it doesn't power on it.
OK, so the core of the problem is here. The SoC firmware is going to
power of the domain during system-wide suspend, no matter what Linux
tries to do. So there's a fundamental disconnect between what Linux
thinks is the state of the power domain and the actual hardware state.
I'm not sure how to work around that other than if the firmware is
always going to power off the domain, then GENPD_FLAG_ACTIVE_WAKEUP
cannot be used for that domain, since it's effectively ignored.
> The wakeup_path of all my uarts is set here [3] because devices are
> wakeup capable [4].
Ok, but now This behavior is now changed in v6.12-rc1[6] (introduced by
this[7] series.) Now, UARTs default to wakeup capable (not enabled),
and wakeups are only enabled if the DT property `wakeup-source` is used.
This should at least allow you to focus on only UARTs that are intended
as wakeup sources for the platform, instead of the current (pre v.6.12) behavior
where all UARTs default to wakeup-enabled.
Kevin
> It was added by commit 8512220c5782d [5].
> If I remove the wakeup_path modification (diff at the end of the email),
> Théo's proposal works well. But it's probably too rough, and I have no
> idea about the impact on other platforms.
>
> If you have an idea to fix correctly this wakeup_path issue, please let
> me know :)
>
> [1]
> https://elixir.bootlin.com/linux/v6.11/source/drivers/pmdomain/core.c#L1372
> [2]
> https://elixir.bootlin.com/linux/v6.11/source/drivers/pmdomain/core.c#L1427
> [3]
> https://elixir.bootlin.com/linux/v6.10.10/source/drivers/base/power/main.c#L1687
> [4]
> https://elixir.bootlin.com/linux/v6.11/source/drivers/tty/serial/8250/8250_omap.c#L1526
> [5]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8512220c5782d
[6] https://elixir.bootlin.com/linux/v6.12-rc1/source/drivers/tty/serial/8250/8250_omap.c#L1525
[7] https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/
prev parent reply other threads:[~2024-10-04 19:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 13:05 [PATCH] serial: 8250_omap: Set the console genpd always on if no console suspend Thomas Richard
2023-10-23 7:44 ` Tony Lindgren
2023-10-24 14:53 ` Thomas Richard
2023-10-24 15:24 ` Greg KH
2023-10-23 21:31 ` Kevin Hilman
2023-10-24 4:51 ` Tony Lindgren
2023-10-24 18:36 ` Kevin Hilman
2023-10-25 6:41 ` Tony Lindgren
2023-10-31 10:15 ` Thomas Richard
2023-10-31 10:52 ` Tony Lindgren
2023-10-31 17:34 ` Kevin Hilman
2023-11-22 14:47 ` Théo Lebrun
2023-11-24 5:37 ` Tony Lindgren
2023-11-24 10:39 ` Théo Lebrun
2023-11-24 10:54 ` Tony Lindgren
2023-11-28 4:05 ` Kevin Hilman
2023-11-28 4:11 ` Tony Lindgren
2023-11-28 4:52 ` Kevin Hilman
2023-11-28 5:05 ` Tony Lindgren
2023-11-27 11:22 ` VAMSHI GAJJELA
2024-08-09 19:04 ` Kevin Hilman
2024-08-13 9:00 ` Greg KH
2024-08-13 17:18 ` Kevin Hilman
2024-08-20 9:15 ` Thomas Richard
2024-09-16 14:03 ` Thomas Richard
2024-10-04 19:23 ` Kevin Hilman [this message]
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=7ha5fjlljg.fsf@baylibre.com \
--to=khilman@kernel.org \
--cc=d-gole@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=gregory.clement@bootlin.com \
--cc=jirislaby@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=thomas.richard@bootlin.com \
--cc=tony@atomide.com \
--cc=u-kumar1@ti.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;
as well as URLs for NNTP newsgroup(s).