From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755435AbcIMHVd (ORCPT ); Tue, 13 Sep 2016 03:21:33 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:29331 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755393AbcIMHV3 (ORCPT ); Tue, 13 Sep 2016 03:21:29 -0400 X-AuditID: cbfec7f4-f791c6d000006eac-75-57d7a8f45cfc Subject: Re: [RFC/RFT][PATCH v2 5/7] PM / runtime: Flag to indicate PM sleep transitions in progress To: "Rafael J. Wysocki" , Lukas Wunner Cc: Linux PM list , Greg Kroah-Hartman , Alan Stern , Linux Kernel Mailing List , Tomeu Vizoso , Mark Brown , Kevin Hilman , Ulf Hansson , "Luis R. Rodriguez" From: Marek Szyprowski Message-id: Date: Tue, 13 Sep 2016 09:21:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-version: 1.0 In-reply-to: <6063056.2MKrxSTWdb@vostro.rjw.lan> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsWy7djP87pfVlwPN/i71chi6sMnbBbNi9ez WTzd/JjJ4vKuOWwWn3uPMFq8eC5t8fzkXmaLM6cvsVpM+H2BzaJv7SU2i+Nrwx24PXbcXcLo sWlVJ5vHnWt72Dz2z13D7rHlajuLx+y7Pxg91m+5yuLxeZOcx4z2bawBnFFcNimpOZllqUX6 dglcGZ8f9zEW/BOtuL90O3MD413BLkZODgkBE4n7PxoZIWwxiQv31rN1MXJxCAksZZS4tbyb HcL5zCixa8tDJpiOV2v3MkEkljFKfFsxF8p5ziix+PUbNpAqYYE0ifW3LrKC2CIC3hJrzv5n BiliFmhlllj7pgUswSZgKNH1tgusgVfATqL35i2wFSwCqhLnN9wDqxEViJG4e+MsVI2gxI/J 91hAbE4BA4lt7SvB4swCVhLP/rWyQtjyEpvXvGWGOPUeu0TLXOkuRg4gW1Zi0wGosIvElxn/ WSBsYYlXx7ewQ9gyEp0dB6G+7GeUaGrVhrBnMEqce8sLYVtLHD5+EWoVn8SkbdOZIcbzSnS0 CUGUeEhc2D6fBSLsKNE2OxYSPB8ZJdY9+Mk2gVF+FpJnZiF5YBaSBxYwMq9iFEktLc5NTy02 0StOzC0uzUvXS87P3cQITE2n/x3/soNx8TGrQ4wCHIxKPLwNq6+FC7EmlhVX5h5ilOBgVhLh fb/kergQb0piZVVqUX58UWlOavEhRmkOFiVx3j0LroQLCaQnlqRmp6YWpBbBZJk4OKUaGLtr 4hIXiM4xeRhb2FMYOUvs4JZd119+9Fa/Hq2XrePJVsYmMXs/Pz93W6TbX4cPZwKmmMvk/zJS 3De7t/Zr55xZZ2v5fy76e7/l1YkDmW84Je3/7dk+5aRcbRGre42iwqpk1oxNkh5rN8gcKhHf fDRrxlzJPX5T/jZOdQ/Yp6DafuxHS8GZLUosxRmJhlrMRcWJAHOd6nZJAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsVy+t/xa7rHVlwPN/jzl99i6sMnbBbNi9ez WTzd/JjJ4vKuOWwWn3uPMFq8eC5t8fzkXmaLM6cvsVpM+H2BzaJv7SU2i+Nrwx24PXbcXcLo sWlVJ5vHnWt72Dz2z13D7rHlajuLx+y7Pxg91m+5yuLxeZOcx4z2bawBnFFuNhmpiSmpRQqp ecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpwcA5wD1bSt0twy/j8uI+x 4J9oxf2l25kbGO8KdjFyckgImEi8WruXCcIWk7hwbz1bFyMXh5DAEkaJeQ2z2EASQgLPGSUu HE0DsYUF0iTW37rICmKLCHhLrDn7nxmi5iOjxKFtXCDNzALtzBJ/DjeCTWUTMJToetsFNohX wE6i9+YtsDiLgKrE+Q33gAZxcIgKxEis70uAKBGU+DH5HguIzSlgILGtfSVYK7OAmcSXl4dZ IWx5ic1r3jJPYBSYhaRlFpKyWUjKFjAyr2IUSS0tzk3PLTbUK07MLS7NS9dLzs/dxAiM023H fm7ewXhpY/AhRgEORiUe3obV18KFWBPLiitzDzFKcDArifC+X3I9XIg3JbGyKrUoP76oNCe1 +BCjKdAPE5mlRJPzgSkkryTe0MTQ3NLQyNjCwtzISEmct+TDlXAhgfTEktTs1NSC1CKYPiYO TqkGxsCzSlXsT9sZuMXfzfjz23h6UGOinnX9mclWTzNFV/3Nyj1bZpj5poSldkF08yKT5+cV BSsfusubZARITr8+Y1f865vBFeKZJsnXPbhPBk+JWV9zdZOn5/aoKt5JDp8i4vLuvm8vua99 PF6gXEPX9KWnpBP/UbnF3jYbtMR4t8d//RSdqOmgxFKckWioxVxUnAgA2BJOYekCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160913072124eucas1p2443ced6c2fbaad5a5ae8cf7a8b6098eb X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRs=?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRtT?= =?UTF-8?B?YW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20160912211933eucas1p24f4353d41f7bd1ad2845fe415ef66a7c X-RootMTR: 20160912211933eucas1p24f4353d41f7bd1ad2845fe415ef66a7c References: <27296716.H9VWo8ShOm@vostro.rjw.lan> <3677187.4hCpDgWMoX@vostro.rjw.lan> <20160912140727.GA591@wunner.de> <6063056.2MKrxSTWdb@vostro.rjw.lan> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, On 2016-09-12 23:25, Rafael J. Wysocki wrote: > On Monday, September 12, 2016 04:07:27 PM Lukas Wunner wrote: >> On Thu, Sep 08, 2016 at 11:29:48PM +0200, Rafael J. Wysocki wrote: >>> Introduce a new flag in struct dev_pm_info, pm_sleep_in_progress, to >>> indicate that runtime PM has been disabled because of a PM sleep >>> transition in progress. >> [...] >>> That will allow helpers like pm_runtime_get_sync() to be called >>> during system sleep transitions without worrying about possible >>> error codes they may return because runtime PM is disabled at >>> that point. >> I have a suspicion that this patch papers over the direct_complete bug >> I reported Sep 10 and that the patch is unnecessary once that bug is >> fixed. > It doesn't paper over anything, but it may not be necessary anyway. > >> AFAICS, runtime PM is only disabled in two places during the system >> sleep process: In __device_suspend() for devices using direct_complete, >> and __device_suspend_late() for all devices. >> >> In both of these phases (dpm_suspend() and dpm_suspend_late()), the >> device tree is walked bottom-up. Since we've reordered consumers to >> the back of dpm_list, they will be treated *before* their suppliers. >> Thus, runtime PM is disabled on the consumers first, and only later >> on the suppliers. >> >> Then how can it be that runtime PM is already disabled on the supplier? > Actually, I think that this was a consequence of a bug in device_reorder_to_tail() > that was present in the previous iteration of the patchset (it walked suppliers > instead of consumers). > >> The only scenario I can imagine is that the supplier chose to exercise >> direct_complete, thus was pm_runtime_disabled() in the __device_suspend() >> phase, and the consumer did *not* choose to exercise direct_complete and >> later tried to runtime resume its suppliers and itself. >> >> I assume this patch is a replacement for Marek's [v2 08/10]. >> @Marek, does this scenario match with what you witnessed? > It is not strictly a replacement for it. The Marek's patch was the > reason to post it, but I started to think about this earlier. > > Some people have complained to me about having to deal with error codes > returned by the runtime PM framework during system suspend, so I thought > it might be useful to deal with that too. > > That said it probably is not necessary right now. I've tested this patchset without this patch and system sleep with device link enabled worked fine. However this might be also a consequence of enabling runtime pm during system sleep since v4.8-rc1. It looks that for now this patch can be skipped until a real use case for it appears. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland