[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4a043533-009f-4db9-b107-c8374be28d2b@samsung.com>
Date: Wed, 7 Feb 2024 12:16:26 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM
<linux-pm@...r.kernel.org>, Ulf Hansson <ulf.hansson@...aro.org>, Tejun Heo
<tj@...nel.org>, Nathan Chancellor <nathan@...nel.org>, LKML
<linux-kernel@...r.kernel.org>, Stanislaw Gruszka
<stanislaw.gruszka@...ux.intel.com>, Lai Jiangshan <jiangshanlai@...il.com>,
Naohiro.Aota@....com, kernel-team@...a.com
Subject: Re: [PATCH v1] PM: sleep: Restore asynchronous device resume
optimization
On 07.02.2024 11:38, Rafael J. Wysocki wrote:
> On Wed, Feb 7, 2024 at 11:31 AM Marek Szyprowski
> <m.szyprowski@...sung.com> wrote:
>> On 09.01.2024 17:59, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki<rafael.j.wysocki@...el.com>
>>>
>>> Before commit 7839d0078e0d ("PM: sleep: Fix possible deadlocks in core
>>> system-wide PM code"), the resume of devices that were allowed to resume
>>> asynchronously was scheduled before starting the resume of the other
>>> devices, so the former did not have to wait for the latter unless
>>> functional dependencies were present.
>>>
>>> Commit 7839d0078e0d removed that optimization in order to address a
>>> correctness issue, but it can be restored with the help of a new device
>>> power management flag, so do that now.
>>>
>>> Signed-off-by: Rafael J. Wysocki<rafael.j.wysocki@...el.com>
>>> ---
>> This patch finally landed in linux-next some time ago as 3e999770ac1c
>> ("PM: sleep: Restore asynchronous device resume optimization"). Recently
>> I found that it causes a non-trivial interaction with commit
>> 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement
>> for unbound workqueues"). Since merge commit 954350a5f8db in linux-next
>> system suspend/resume fails (board doesn't wake up) on my old Samsung
>> Exynos4412-based Odroid-U3 board (ARM 32bit based), which was rock
>> stable for last years.
>>
>> My further investigations confirmed that the mentioned commits are
>> responsible for this issue. Each of them separately (3e999770ac1c and
>> 5797b1c18919) doesn't trigger any problems. Reverting any of them on top
>> of linux-next (with some additional commit due to code dependencies)
>> also fixes/hides the problem.
>>
>> Let me know if You need more information or tests on the hardware. I'm
>> open to help debugging this issue.
> If you echo 0 to /sys/power/pm_async before suspending the system,
> does it still fail?
In such case it works fine.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Powered by blists - more mailing lists