All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Kevin Hilman <khilman@kernel.org>
Cc: Thomas Richard <thomas.richard@bootlin.com>,
	gregkh@linuxfoundation.org, jirislaby@kernel.org,
	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: Wed, 25 Oct 2023 09:41:31 +0300	[thread overview]
Message-ID: <20231025064131.GZ27774@atomide.com> (raw)
In-Reply-To: <7hjzrbj29t.fsf@baylibre.com>

* Kevin Hilman <khilman@kernel.org> [231024 18:36]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Kevin Hilman <khilman@kernel.org> [231023 21:31]:
> >> Instead, what should be happening is that when `no_console_suspend` is
> >> set, there should be an extra pm_runtime_get() which increases the
> >> device usecount such that the device never runtime suspends, and thus
> >> the domain will not get powered off.
> >
> > We already have the runtime PM usage count kept in the driver (unless
> > there's a bug somewhere). The issue is that on suspend the power domain
> > still gets shut down.
> >
> > I suspect that some of the SoC power domains get
> > force shut down on suspend somewhere?
> 
> If setting GENPD_FLAG_ALWAYS_ON works as this patch proposes, then a
> force shutdown would override that genpd flag also, so I suspect the 
> runtime PM usage count is not correct.

OK good point.

> I quick skim of 8250_omap.c, and I don't see any pm_runtime_get() calls
> that are conditional on no_console_suspend, which is what I would
> suspect for the domain to stay on.

If a serial console is attached, we now have runtime PM usage count
always kept. Users can detach the console via sysfs as needed. See these
two earlier commits from Andy:

a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console")

Sounds like there's a bug somewhere. It's worth verifying if the runtime
PM usage count is kept for 8250_omap on suspend.

Thomas, care to check your test case with the attached debug hack
and by adding a call for pm_runtime_get_usage_count() on the suspend
path?

Regards,

Tony

8< -------------------------------
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -129,6 +129,11 @@ static inline void pm_runtime_get_noresume(struct device *dev)
 	atomic_inc(&dev->power.usage_count);
 }
 
+static inline int pm_runtime_get_usage_count(struct device *dev)
+{
+	return atomic_read(&dev->power.usage_count);
+}
+
 /**
  * pm_runtime_put_noidle - Drop runtime PM usage counter of a device.
  * @dev: Target device.

  reply	other threads:[~2023-10-25  6:41 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 [this message]
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

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=20231025064131.GZ27774@atomide.com \
    --to=tony@atomide.com \
    --cc=d-gole@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.clement@bootlin.com \
    --cc=jirislaby@kernel.org \
    --cc=khilman@kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=thomas.richard@bootlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.