From: "Rafael J. Wysocki" <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Rafael J. Wysocki" <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>, Linux PM <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, linux-arm-msm <linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, freedreno <freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> Subject: Re: [PATCH v12 1/4] iommu/arm-smmu: Add pm_runtime/sleep ops Date: Mon, 23 Jul 2018 13:05:22 +0200 [thread overview] Message-ID: <CAJZ5v0h4FLhMJY0fg5q0vBewnNssmpvXHzADg=iDFSfq6Dg=rw@mail.gmail.com> (raw) In-Reply-To: <20180723055959eucas1p15a381f2a1287a28e4f78f1fb5fc8e37d~D6gOgxXLK0412704127eucas1p1R-MHMrYXj8g+pqW5MlFJXMulaTQe2KTcn/@public.gmane.org> On Mon, Jul 23, 2018 at 7:59 AM, Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote: > Hi Rafael, > > On 2018-07-11 22:36, Rafael J. Wysocki wrote: >> On Wed, Jul 11, 2018 at 3:40 PM, Marek Szyprowski >> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote: [cut] >>> Frankly, if there are no other reasons I suggest to wire system >>> suspend/resume to pm_runtime_force_* helpers: >>> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, >>> pm_runtime_force_resume). >> Not a good idea at all IMO. >> >> Use PM driver flags rather I'd say. > > Frankly, till now I wasn't aware of the DPM_FLAG_* in struct dev_pm_info > 'driver_flags'. They are a relatively recent addition. > I've briefly checked them but I don't see the equivalent > of using SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, > pm_runtime_force_resume): keep device suspend if it was runtime suspended > AND really call pm_runtime_suspend if it was not runtime suspended on > system suspend. DPM_FLAG_SMART_SUSPEND is expected to cause that to happen. If you want the device to remain in suspend after the system-wide resume from sleep (if possible), you can set DPM_FLAG_LEAVE_SUSPENDED for it too. Currently a caveat is that genpd still doesn't support the flags. I have patches for that, but I haven't got to posting them yet. If you are interested, I can push this work forward relatively quickly, so please let me know. >>> This way you will have everything related to suspending and resuming in >>> one place and you would not need to bother about all possible cases (like >>> suspending from runtime pm active and suspending from runtime pm suspended >>> cases as well as restoring proper device state on resume). This is >>> especially important in recent kernel releases, where devices are >>> system-suspended regardless their runtime pm states (in older kernels >>> devices were first runtime resumed for system suspend, what made code >>> simpler, but wasn't best from power consumption perspective). >>> >>> If you go this way, You only need to ensure that runtime resume will also >>> restore proper device state besides enabling all the clocks. This will >>> also prepare your driver to properly operate inside power domain, where it >>> is possible for device to loose its internal state after runtime suspend >>> when respective power domain has been turned off. >> I'm not sure if you are aware of the pm_runtime_force_* limitations, though. > > What are those limitations? First off, they don't work with middle-layer code implementing its own PM callbacks that actually operate on devices (like the PCI bus type or the generic ACPI PM domain). This means that drivers using them may not work on systems with ACPI, for example. Second, pm_runtime_force_resume() will always try to leave the device in suspend during system-wide resume from sleep which may not be desirable. Finally, they expect the runtime PM status to be updated by system-wide PM callbacks of devices below the one using them (eg. its children and their children etc) which generally is not required and may not take place unless the drivers of those devices use pm_runtime_force_* themselves. So careful there.
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rafael@kernel.org> To: Marek Szyprowski <m.szyprowski@samsung.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Tomasz Figa <tfiga@chromium.org>, Vivek Gautam <vivek.gautam@codeaurora.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, "list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Robin Murphy <robin.murphy@arm.com>, Will Deacon <will.deacon@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Alex Williamson <alex.williamson@redhat.com>, Rob Clark <robdclark@gmail.com>, Linux PM <linux-pm@vger.kernel.org>, freedreno <freedreno@lists.freedesktop.org>, Stephen Boyd <sboyd@kernel.org>, Sricharan R <sricharan@codeaurora.org>, Archit Taneja <architt@codeaurora.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Jordan Crouse <jcrouse@codeaurora.org> Subject: Re: [PATCH v12 1/4] iommu/arm-smmu: Add pm_runtime/sleep ops Date: Mon, 23 Jul 2018 13:05:22 +0200 [thread overview] Message-ID: <CAJZ5v0h4FLhMJY0fg5q0vBewnNssmpvXHzADg=iDFSfq6Dg=rw@mail.gmail.com> (raw) In-Reply-To: <20180723055959eucas1p15a381f2a1287a28e4f78f1fb5fc8e37d~D6gOgxXLK0412704127eucas1p1R@eucas1p1.samsung.com> On Mon, Jul 23, 2018 at 7:59 AM, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hi Rafael, > > On 2018-07-11 22:36, Rafael J. Wysocki wrote: >> On Wed, Jul 11, 2018 at 3:40 PM, Marek Szyprowski >> <m.szyprowski@samsung.com> wrote: [cut] >>> Frankly, if there are no other reasons I suggest to wire system >>> suspend/resume to pm_runtime_force_* helpers: >>> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, >>> pm_runtime_force_resume). >> Not a good idea at all IMO. >> >> Use PM driver flags rather I'd say. > > Frankly, till now I wasn't aware of the DPM_FLAG_* in struct dev_pm_info > 'driver_flags'. They are a relatively recent addition. > I've briefly checked them but I don't see the equivalent > of using SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, > pm_runtime_force_resume): keep device suspend if it was runtime suspended > AND really call pm_runtime_suspend if it was not runtime suspended on > system suspend. DPM_FLAG_SMART_SUSPEND is expected to cause that to happen. If you want the device to remain in suspend after the system-wide resume from sleep (if possible), you can set DPM_FLAG_LEAVE_SUSPENDED for it too. Currently a caveat is that genpd still doesn't support the flags. I have patches for that, but I haven't got to posting them yet. If you are interested, I can push this work forward relatively quickly, so please let me know. >>> This way you will have everything related to suspending and resuming in >>> one place and you would not need to bother about all possible cases (like >>> suspending from runtime pm active and suspending from runtime pm suspended >>> cases as well as restoring proper device state on resume). This is >>> especially important in recent kernel releases, where devices are >>> system-suspended regardless their runtime pm states (in older kernels >>> devices were first runtime resumed for system suspend, what made code >>> simpler, but wasn't best from power consumption perspective). >>> >>> If you go this way, You only need to ensure that runtime resume will also >>> restore proper device state besides enabling all the clocks. This will >>> also prepare your driver to properly operate inside power domain, where it >>> is possible for device to loose its internal state after runtime suspend >>> when respective power domain has been turned off. >> I'm not sure if you are aware of the pm_runtime_force_* limitations, though. > > What are those limitations? First off, they don't work with middle-layer code implementing its own PM callbacks that actually operate on devices (like the PCI bus type or the generic ACPI PM domain). This means that drivers using them may not work on systems with ACPI, for example. Second, pm_runtime_force_resume() will always try to leave the device in suspend during system-wide resume from sleep which may not be desirable. Finally, they expect the runtime PM status to be updated by system-wide PM callbacks of devices below the one using them (eg. its children and their children etc) which generally is not required and may not take place unless the drivers of those devices use pm_runtime_force_* themselves. So careful there.
next prev parent reply other threads:[~2018-07-23 11:05 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-08 17:34 [PATCH v12 0/4] iommu/arm-smmu: Add runtime pm/sleep support Vivek Gautam 2018-07-08 17:34 ` Vivek Gautam [not found] ` <20180708173413.1965-1-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-07-08 17:34 ` [PATCH v12 1/4] iommu/arm-smmu: Add pm_runtime/sleep ops Vivek Gautam 2018-07-08 17:34 ` Vivek Gautam 2018-07-11 9:50 ` Rafael J. Wysocki [not found] ` <17407514.unFVTGoGrn-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org> 2018-07-11 10:55 ` Vivek Gautam 2018-07-11 10:55 ` Vivek Gautam [not found] ` <CAFp+6iHxJucfzJJeEvSToG4p2zADjDb9F0L8h053x-JKAy55mg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-11 11:11 ` Rafael J. Wysocki 2018-07-11 11:11 ` Rafael J. Wysocki [not found] ` <CAJZ5v0gbkdkx_+oHYiPz=SFdFCLm38hsi1TmJ2Jdc7j73TNtzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-11 12:51 ` Tomasz Figa 2018-07-11 12:51 ` Tomasz Figa [not found] ` <CAAFQd5Cqd=J+_nqRc_sx=sq2ayxwSRMgygvffuHH9nC5R_LjdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-11 13:40 ` Marek Szyprowski 2018-07-11 13:40 ` Marek Szyprowski 2018-07-11 20:36 ` Rafael J. Wysocki 2018-07-11 20:36 ` Rafael J. Wysocki [not found] ` <CAJZ5v0g0NwkLmd=tJ0sT4pc8FJSRE8sEu5GRQ7KUUd+YedzjMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-23 5:59 ` Marek Szyprowski 2018-07-23 5:59 ` Marek Szyprowski [not found] ` <20180723055959eucas1p15a381f2a1287a28e4f78f1fb5fc8e37d~D6gOgxXLK0412704127eucas1p1R-MHMrYXj8g+pqW5MlFJXMulaTQe2KTcn/@public.gmane.org> 2018-07-23 11:05 ` Rafael J. Wysocki [this message] 2018-07-23 11:05 ` Rafael J. Wysocki 2018-07-12 10:57 ` Vivek Gautam 2018-07-12 10:57 ` Vivek Gautam [not found] ` <CAFp+6iFxiM0DDnRqUameH6XOYjgdAF8ysuXXAjkc8zsod-dVcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-16 8:51 ` Rafael J. Wysocki 2018-07-16 8:51 ` Rafael J. Wysocki [not found] ` <CAJZ5v0hq3bLUbXNsr_ig7D72td_wqRP063x1AseP85F5UWs8VA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-16 10:11 ` Vivek Gautam 2018-07-16 10:11 ` Vivek Gautam [not found] ` <010cb56a-36e8-e729-1fe7-738048eb551d-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-07-16 10:23 ` Rafael J. Wysocki 2018-07-16 10:23 ` Rafael J. Wysocki 2018-07-08 17:34 ` [PATCH v12 2/4] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device Vivek Gautam 2018-07-08 17:34 ` Vivek Gautam 2018-07-11 9:51 ` Rafael J. Wysocki [not found] ` <1694664.FhRBrgajmF-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org> 2018-07-11 10:05 ` Tomasz Figa 2018-07-11 10:05 ` Tomasz Figa [not found] ` <CAAFQd5COVfXRBuq2ofHoOvNb+cMVmAFDaekh5KM4DBB1ZEf5pA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-11 10:59 ` Rafael J. Wysocki 2018-07-11 10:59 ` Rafael J. Wysocki [not found] ` <CAJZ5v0hMQJQ0Z-H2OLaeCdT+-MW_eSWmg7saVzkpDqJ-=i3DnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-11 11:30 ` Vivek Gautam 2018-07-11 11:30 ` Vivek Gautam 2018-07-08 17:34 ` [PATCH v12 3/4] iommu/arm-smmu: Add the device_link between masters and smmu Vivek Gautam 2018-07-08 17:34 ` Vivek Gautam 2018-07-11 9:53 ` Rafael J. Wysocki [not found] ` <5179668.PHK6S3sxLu-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org> 2018-07-11 10:36 ` Vivek Gautam 2018-07-11 10:36 ` Vivek Gautam [not found] ` <741cc78b-59a7-5289-e42f-1511ebedb15d-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-07-12 12:41 ` Vivek Gautam 2018-07-12 12:41 ` Vivek Gautam [not found] ` <CAFp+6iFTgEhPLYQEyBX_Fb0k3n0OzGhKuSoBNV5XzpD01+V8qw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-16 8:55 ` Rafael J. Wysocki 2018-07-16 8:55 ` Rafael J. Wysocki [not found] ` <CAJZ5v0iQ2wxsXvuaLK2M9a_Jwe_fnwR2Afrq_Oa8h0--Ch7-5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-16 11:46 ` Vivek Gautam 2018-07-16 11:46 ` Vivek Gautam [not found] ` <93d16301-4bef-203f-24de-4d010de84b22-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2018-07-17 7:46 ` Rafael J. Wysocki 2018-07-17 7:46 ` Rafael J. Wysocki [not found] ` <CAJZ5v0ijB6ZX9q0i+YrkWg1-nQBx+FuTjbGq1xRoJS113uoA-g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-17 8:30 ` Vivek Gautam 2018-07-17 8:30 ` Vivek Gautam 2018-07-18 9:30 ` Vivek Gautam 2018-07-18 9:30 ` Vivek Gautam [not found] ` <CAFp+6iGcwdK=wyPf++u3B+ORghuB1YhYmnJLSwvt1efG9H4YeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2018-07-18 12:43 ` Robin Murphy 2018-07-18 12:43 ` Robin Murphy [not found] ` <48139f68-5a79-8531-00fa-fbdd787f50f5-5wv7dgnIgG8@public.gmane.org> 2018-07-18 13:31 ` Vivek Gautam 2018-07-18 13:31 ` Vivek Gautam 2018-07-08 17:34 ` [PATCH v12 4/4] iommu/arm-smmu: Add support for qcom, smmu-v2 variant Vivek Gautam 2018-07-08 17:34 ` [PATCH v12 4/4] iommu/arm-smmu: Add support for qcom,smmu-v2 variant Vivek Gautam
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='CAJZ5v0h4FLhMJY0fg5q0vBewnNssmpvXHzADg=iDFSfq6Dg=rw@mail.gmail.com' \ --to=rafael-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \ --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=will.deacon-5wv7dgnIgG8@public.gmane.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: linkBe 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.