Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1b1aa20aa3b8f8255fa05d61c7fa094650dee319.camel@nxp.com>
Subject: Re: [PATCH v2] PM: runtime: Return properly from rpm_resume() if
 dev->power.needs_force_resume flag is set
From:   Liu Ying <victor.liu@nxp.com>
To:     Ulf Hansson <ulf.hansson@linaro.org>
Cc:     linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org, linux-imx@nxp.com,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue, 27 Sep 2022 15:46:21 +0800
In-Reply-To: <CAPDyKFr0XjrU_udKoUKQ_q8RWaUkyqL+8fV-7s1CTMqi7u3-Rg@mail.gmail.com>
References: <20220923124904.1373936-1-victor.liu@nxp.com>
         <CAPDyKFqdHX=o4V4K8GdCr4wQ5sjr=JMG6CFAy1849=CtfoSgRQ@mail.gmail.com>
         <75366bfac9fcd4f8c35309193705f0277a164ae4.camel@nxp.com>
         <CAPDyKFr0XjrU_udKoUKQ_q8RWaUkyqL+8fV-7s1CTMqi7u3-Rg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.4-0ubuntu1 
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YytERnhKQzJCNzIzbHdMM09JbjNkTHVob05GU3NIemxmQVN3NWplY0ptV3Ay?=
 =?utf-8?B?UmF1bEZDNWJqR2NteTR4R2FwbUlNS3ZGNytpK1BKZWJUWTVGcEdYdkQyWVVR?=
 =?utf-8?B?bzNlREdBbVpSTUVJR3V4dkVPVng0YlhFb2xnZXdGekhrcWRTSGNTMFZSS2Nk?=
 =?utf-8?B?RitraHM1QjFKM1lFbzlDc08vY3lad051YVJCN2s1VzVsTGpuWEtDcHJ0S3VP?=
 =?utf-8?B?QVhyZXZKOTBIaHdHMTg3U3U4WHM0bGZJclNRV01RVXFXZEo5V1l5MElYN1VD?=
 =?utf-8?B?VFR5aGZFZnMyUHpybGZPYjJpOERyTTd2UmtJRmhYajQ5bzFBNEhiVmxMdmFM?=
 =?utf-8?B?UzFDb29WaWd1TVc0UGpxTStJZk5VMFFVNUxqR1JpVXQrR0pJamNQMEwzbkx4?=
 =?utf-8?B?WVF0cnFacUpYbElvTTVxek8wYVBCRERZTVU3R1NWTU1kajJMb0RsdXFsaXdY?=
 =?utf-8?B?SE8zMUg2dmJMRU80QVAxQXZERGZLL3pNMDZydSs5QXYwNXllVHZBYjdyaXlY?=
 =?utf-8?B?R3EyMXFyR0NQaW9HTkVHZnJ2YldrdDRqeFd1T3k4b1UxWlo2NGdOTit5SVU3?=
 =?utf-8?B?OC9GVjlydUQ4Ujl3bG8xVzBCNnRaUFB4eG5GTW5sNzl2MHpwb3dQdy8yMEVj?=
 =?utf-8?B?VGVna2VPdEZjcTVwbWQxazdPTzVseGI2TDFDTkl5NzlrSC9pMytXbkVwUWdI?=
 =?utf-8?B?Smhkd1RKczlBc3Z5ZjFQS05BblBoVi9sMGZBU2RxTTFqY2orNUhCWDgvb0wx?=
 =?utf-8?B?bFEzamQrRTVIdS9PVWxyVFVmMkdxZ0h0Z08zQVFvaDAyTU9JTDgrYUErdTQ3?=
 =?utf-8?B?MGlWUkdZdlY3bTErK0t3enVPMUQ2ZnJ2K3lPcld2UTRXblpGRzdSbU1KSzRC?=
 =?utf-8?B?MGJ1VjhtRnhjWWVCa2tMbXd6dExKeVU2SHZKaG4rcjBVeHpTd3BDV2pvSlNu?=
 =?utf-8?B?dlRjNHlXUjN6R3lRaDNrYnF0UFMrQi9tcVdId2xjd0N5clNFN3hQV2IzN3J5?=
 =?utf-8?B?QW5HcTFJc09qdVBpbjNJLzV4cVlNeFRLb0xZOWk1b2JvRnMwOXNHQmhtaXho?=
 =?utf-8?B?S2xKRTAwdVlUVzljbFpBUkNudmFhcVZ3WTZVb1BmWGRPcy9kWG5ZbzVGL0pk?=
 =?utf-8?B?cnhpZm5Yd2dBL2ErcVE0c3NyanZzcDIxVXBwMjlyMUU3U3JFVEpZM3daSzdt?=
 =?utf-8?B?OVNienoyRHEzNkVxNHJmYlhPMEQ4dG5QNG5YSm51MEl0QjBSTElXZjRwSzFB?=
 =?utf-8?B?RU9ZM3YvOGg5UllMSmVVVXhuRVBvbWJDQSt6TDRqcUlicnNNREVJbCtScnJH?=
 =?utf-8?B?L3hwUHUwQ3pXMU5SaVB0T1FoSjVJOXhjVXJvMmxjcG0zUXAwa1lHeGpuVkYx?=
 =?utf-8?B?dkczc1RRVUx2cERQNU9xYUhuWEpqbW9naU1KSW5WSnYxQTBmRjBDL3dkZ21w?=
 =?utf-8?B?ZDZQaG1SeWNzZVVBWnE5K3VCWEIycS9qdXVTcGZ4OWd5OSt0elNEeWtvUFlk?=
 =?utf-8?B?VEhFak53enVaL0hTeU1remhNWHVMeHdJS0dDMy9Zc3o1TStJWExHZHAzeDI3?=
 =?utf-8?B?RzA4QXkyaWl3RVlCcDFnbTFqMWpKMzh0Z2JGWnAxMDgwMk82OGFuQWd0QkdT?=
 =?utf-8?B?ZjZ2VVZCTE1xZXdqU2UvM1QxTjlzRFhtSmdEMk9UbU44eW15WHN6Y2NiSTB4?=
 =?utf-8?B?R0V2WFVrUTdMZUFWM1Z3WGFnNXUxb0RZd2dab0o5UCt3UDdRSmMzM095dVB4?=
 =?utf-8?B?T3p2dGpTbVNrV3IweU9rdm5EWWJKRndPcVgzcktQUHNaOXQ3bURDRWZrUmZa?=
 =?utf-8?B?SVJYWGxRNkhFdC9OQURSVlJaUVFrQ2xoZE1hMGhyWVRaT0xST01wQlFjd08v?=
 =?utf-8?B?VFJBMUczalZjT1gzYUFOakh6UTdTaGVUUHc2RzhiSVU3eU42cjUwR0h3UVl4?=
 =?utf-8?B?T2JOS2pTWFc5Z0hSblA1c0lYK1dEK3Mzd3FXT0g2Tnh1QUFxUTRRSXZzNnEv?=
 =?utf-8?B?L1N3Q1pPTFN5ckR3bkpZWE16MGs4MkkxQnlWL1hvaWk0WWtWL3lUeSsrczla?=
 =?utf-8?B?ZnliTGFUQThWOFptMVhqWUQzNHRKRnhYaGlzK0pPTDEwT2FnY1FkZWhON29S?=
 =?utf-8?Q?siDlRJo8kX93U/x0iI660e4tD?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 441cfa2c-e138-4bd0-e65a-08daa05c7965
X-MS-Exchange-CrossTenant-AuthSource: AM7PR04MB7046.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2022 07:47:06.2846
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: MtqGZngmktlGCEB6fii5tTxeim4CCFv9FAbzUFRzZpMYJzfdqyQ2ezpwt2IvmpwNdloAGYPwqBvwQ4d0EwlyoA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR04MB7883
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 2022-09-26 at 11:47 +0200, Ulf Hansson wrote:
> On Fri, 23 Sept 2022 at 17:23, Liu Ying <victor.liu@nxp.com> wrote:
> > On Fri, 2022-09-23 at 15:48 +0200, Ulf Hansson wrote:
> > > On Fri, 23 Sept 2022 at 14:47, Liu Ying <victor.liu@nxp.com> wrote:
> > > > After a device transitions to sleep state through it's system
> > > > suspend
> > > > callback pm_runtime_force_suspend(), the device's driver may still
> > > > try
> > > > to do runtime PM for the device(runtime suspend first and then
> > > > runtime
> > > > resume) although runtime PM is disabled by that callback.  The
> > > > runtime
> > > > PM operations would not touch the device effectively and the device
> > > > is
> > > > assumed to be resumed through it's system resume callback
> > > > pm_runtime_force_resume().
> > > 
> > > This sounds like a fragile use case to me. In principle you want to
> > > allow the device to be runtime resumed/suspended, after the device
> > > has
> > > already been put into a low power state through the regular system
> > > suspend callback. Normally it seems better to prevent this from
> > > happening, completely.
> > 
> > Not sure if we really may prevent this from happening completely.
> > 
> > > That said, in this case, I wonder if a better option would be to
> > > point
> > > ->suspend_late() to pm_runtime_force_suspend() and ->resume_early()
> > > to
> > > pm_runtime_force_resume(), rather than using the regular
> > > ->suspend|resume() callbacks. This should avoid the problem, I think,
> > > no?
> > 
> > I thought about this and it actually works for my particular
> > panel-simple case.  What worries me is that the device(DRM device in my
> > case) which triggers the runtime PM operations may also use
> > ->suspend_late/resume_early() callbacks for whatever reasons, hence no
> > fixed order to suspend/resume the two devices(like panel device and DRM
> > device).
> > 
> > Also, not sure if there is any sequence issue by using the
> > ->suspend_late/resume_early() callbacks in the panel-simple driver,
> > since it's written for quite a few display panels which may work with
> > various DRM devices - don't want to break any of them.
> 
> What you are describing here, is the classical problem we have with
> suspend/resume ordering of devices.
> 
> There are in principle two ways to solve this.
> 1. If it makes sense, the devices might be assigned as parent/child.
> 2. If it's more a consumer/supplier thing, we can add a device-link
> between them.

I thought about the two ways for my particular panel-simple case and
the first impression is that it's not straightforward to use them. For
DSI panels(with DRM_MODE_CONNECTOR_DSI connector type), it looks like
panel device's parent is DSI host device(set in mipi_dsi_device_alloc()
). For other types of panels, like DPI panels, many show up in device
tree as child-node of root node and connect a display controller or a
display bridge through OF graph.  Seems that DRM architecture level
lacks some sort of glue code to use the two ways.

Regards,
Liu Ying 

> 
> In this way, the PM core can guarantee that the order becomes correct.
> 
> Kind regards
> Uffe