linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Johan Hovold <johan@kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Saravana Kannan <saravanak@google.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v3 1/5] PM: sleep: Resume children after resuming the parent
Date: Wed, 7 May 2025 16:39:50 +0100	[thread overview]
Message-ID: <b17469ee-0d8c-49ff-8fc8-a3c3cc9964dd@nvidia.com> (raw)
In-Reply-To: <CAJZ5v0jVOG_u=F36aOVh=qu4Ef-5QFAmC+5-fmF_mU8NSr_LnA@mail.gmail.com>



On 07/05/2025 15:56, Rafael J. Wysocki wrote:

...

> So apparently one of the children has not been suspended yet when this
> happens.  That's fine because it should be suspended at one point and
> the parent suspend should be unblocked, so it looks like the child
> suspend doesn't complete for some reason.
> 
>> I will enable the PM_ADVANCED_DEBUG and confirm that making the I2C
>> itself non-async works.
> 
> What probably happens is that after the "PM: sleep: Suspend async
> parents after suspending children" , the i2c clients are suspended
> upfront (because they have no children) and when one of them has
> suspended, it triggers a parent suspend.  The parent suspend then
> waits for the other client to complete suspending, but that cannot
> make progress for some reason.
> 
> Before that patch, the i2c clients would have suspended only after all
> of the "sync" devices following them in dpm_list had been suspended
> (the list is processed in the reverse order during suspend), so it
> looks like there is a hidden dependency between one of the i2c clients
> and a "sync" device.
> 
> If the above supposition is right, flagging the i2c client as "sync"
> will make the problem go away.

So all the I2C controllers are 'sync' devices ...

$ cat /sys/class/i2c-dev/i2c-*/power/async
disabled
disabled
disabled
disabled
disabled
disabled
disabled

The I2C clients on the problematic I2C controller are all 'async' 
devices ...

$ cat /sys/class/i2c-dev/i2c-2/device/2-*/power/async
enabled
enabled
enabled

Setting all these to 'disabled' fixes the problem. However, also just 
setting the 'cypd4226' device to 'sync' fixes the problem (the ina3221 
devices seem to be fine being async). The 'cypd4226' device is 
interesting, because this one is a USB Type-C controller and there is a 
circular dependency between the Type-C and USB PHY (see 
arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts).

If I make the following change then this does fix it ...

diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c 
b/drivers/usb/typec/ucsi/ucsi_ccg.c
index f01e4ef6619d..e9a9df1431af 100644
--- a/drivers/usb/typec/ucsi/ucsi_ccg.c
+++ b/drivers/usb/typec/ucsi/ucsi_ccg.c
@@ -1483,6 +1483,8 @@ static int ucsi_ccg_probe(struct i2c_client *client)

         i2c_set_clientdata(client, uc);

+       device_disable_async_suspend(uc->dev);
+
         pm_runtime_set_active(uc->dev);
         pm_runtime_enable(uc->dev);
         pm_runtime_use_autosuspend(uc->dev);

Is this the right fix for this?

Jon

-- 
nvpublic


  reply	other threads:[~2025-05-07 15:40 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14 12:46 [PATCH v3 0/5] PM: sleep: Improvements of async suspend and resume of devices Rafael J. Wysocki
2025-03-14 12:50 ` [PATCH v3 1/5] PM: sleep: Resume children after resuming the parent Rafael J. Wysocki
2025-05-01  9:51   ` Jon Hunter
2025-05-02 20:33     ` Rafael J. Wysocki
2025-05-07 13:21       ` Jon Hunter
2025-05-07 13:39         ` Rafael J. Wysocki
2025-05-07 14:25           ` Rafael J. Wysocki
2025-05-07 14:39             ` Jon Hunter
2025-05-07 14:56               ` Rafael J. Wysocki
2025-05-07 15:39                 ` Jon Hunter [this message]
2025-05-07 16:43                   ` Rafael J. Wysocki
2025-05-08 13:38                     ` Jon Hunter
2025-05-08 18:06                       ` Rafael J. Wysocki
2025-05-10 11:39                   ` Rafael J. Wysocki
2025-05-10 11:50                     ` Jon Hunter
2025-07-11 13:08   ` Tudor Ambarus
2025-07-11 13:38     ` Rafael J. Wysocki
2025-07-11 13:54       ` Rafael J. Wysocki
2025-07-11 18:30         ` Saravana Kannan
2025-07-12  7:57           ` Rafael J. Wysocki
2025-07-12  7:54         ` Rafael J. Wysocki
2025-07-14  7:09           ` Tudor Ambarus
2025-07-14  7:29             ` Rafael J. Wysocki
2025-07-14 10:35               ` Tudor Ambarus
2025-07-14 12:14                 ` Tudor Ambarus
2025-03-14 13:13 ` [PATCH v3 2/5] PM: sleep: Suspend async parents after suspending children Rafael J. Wysocki
2025-06-02 12:11   ` Chris Bainbridge
2025-06-02 14:29     ` Rafael J. Wysocki
2025-06-02 15:21       ` Mario Limonciello
2025-06-02 19:58         ` Rafael J. Wysocki
2025-06-03  9:38           ` Rafael J. Wysocki
2025-06-03 10:17             ` Chris Bainbridge
2025-06-03 10:29               ` Rafael J. Wysocki
2025-06-03 10:30                 ` Rafael J. Wysocki
2025-06-03 11:37                   ` Rafael J. Wysocki
2025-06-03 11:39                     ` Rafael J. Wysocki
2025-06-03 12:14                       ` Chris Bainbridge
2025-06-03 12:23                         ` Rafael J. Wysocki
2025-06-03 12:26                           ` Chris Bainbridge
2025-06-03 13:04                             ` Rafael J. Wysocki
2025-06-03 13:36                               ` Chris Bainbridge
2025-06-03 13:59                                 ` Rafael J. Wysocki
2025-03-14 13:14 ` [PATCH v3 3/5] PM: sleep: Make suspend of devices more asynchronous Rafael J. Wysocki
2025-03-14 13:16 ` [PATCH v3 4/5] PM: sleep: Make async suspend handle suppliers like parents Rafael J. Wysocki
2025-03-14 13:17 ` [PATCH v3 5/5] PM: sleep: Make async resume handle consumers like children Rafael J. Wysocki
2025-03-14 21:06 ` [PATCH v3 0/5] PM: sleep: Improvements of async suspend and resume of devices Saravana Kannan
2025-03-15 14:57   ` Rafael J. Wysocki
2025-04-08 13:39     ` Rafael J. Wysocki

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=b17469ee-0d8c-49ff-8fc8-a3c3cc9964dd@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=saravanak@google.com \
    --cc=stern@rowland.harvard.edu \
    --cc=ulf.hansson@linaro.org \
    /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).