From: "Rafael J. Wysocki" <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, "Rafael J . Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>, Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, Stanimir Varbanov <stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, "linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains Date: Tue, 25 Apr 2017 23:17:51 +0200 [thread overview] Message-ID: <CAJZ5v0gMzN_zfC_2nnRtYFyFon3-_mnioQhNbDP0wsr91RnagA@mail.gmail.com> (raw) In-Reply-To: <CAPDyKFoJ58pwGz2U90ob8a8cY=hEbE-wLBHZ0BBzqPoLW_wgGA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > On 25 April 2017 at 13:13, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >> >> On 28/03/17 15:13, Jon Hunter wrote: >>> The current generic PM domain framework (GenDP) only allows a single >>> PM domain to be associated with a given device. There are several >>> use-cases for various system-on-chip devices where it is necessary for >>> a PM domain consumer to control more than one PM domain where the PM >>> domains: >>> i). Do not conform to a parent-child relationship so are not nested >>> ii). May not be powered on and off at the same time so need independent >>> control. >>> >>> The solution proposed in this RFC is to allow consumers to explictly >>> control PM domains, by getting a handle to a PM domain and explicitly >>> making calls to power on and off the PM domain. Note that referencing >>> counting is used to ensure that a PM domain shared between consumers >>> is not powered off incorrectly. >>> >>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>> controllers) is an example of a consumer that needs to control more than >>> one PM domain because the logic is partitioned across 3 PM domains which >>> are: >>> - XUSBA: Superspeed logic (for USB 3.0) >>> - XUSBB: Device controller >>> - XUSBC: Host controller >>> >>> These power domains are not nested and can be powered-up and down >>> independently of one another. In practice different scenarios require >>> different combinations of the power domains, for example: >>> - Superspeed host: XUSBA and XUSBC >>> - Superspeed device: XUSBA and XUSBB >>> >>> Although it could be possible to logically nest both the XUSBB and XUSBC >>> domains under the XUSBA, superspeed may not always be used/required and >>> so this would keep it on unnecessarily. >>> >>> Given that Tegra uses device-tree for describing the hardware, it would >>> be ideal that the device-tree 'power-domains' property for generic PM >>> domains could be extended to allow more than one PM domain to be >>> specified. For example, define the following the Tegra210 xHCI device ... >>> >>> usb@70090000 { >>> compatible = "nvidia,tegra210-xusb"; >>> ... >>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>> power-domain-names = "host", "superspeed"; >>> }; >>> >>> This RFC extends the generic PM domain framework to allow a device to >>> define more than one PM domain in the device-tree 'power-domains' >>> property. If there is more than one then the assumption is that these >>> PM domains will be controlled explicitly by the consumer and the device >>> will not be automatically bound to any PM domain. >> >> Any more comments/inputs on this? I can address Rajendra's feedback, but >> before I did I wanted to see if this is along the right lines or not? > > I discussed this with Rafael at the OSPM summit in Pisa a couple of > weeks ago. Apologize for the delay in providing additional feedback. > > First, whether the problem is really rare, perhaps adding a new > API/framework can't be justified - then it may be better to add some > kind of aggregation layer on top of the current PM domain > infrastructure (something along the first attempt you made for genpd). > That was kind of Rafael's thoughts (Rafael, please correct me if I am > wrong). We were talking about the original idea behind the pm_domain pointer concept, which was about adding a set of PM operations above the bus type/class layer, which could be used for intercepting bus-type PM operations and providing some common handling above them. This is still relevant IMO. The basic observation here is that the PM core takes only one set of PM operation per device into account and therefore, in every stage of system suspend, for example, the callback invoked by it has to take care of all actions that need to be carried out for the given device, possibly by invoking callbacks from other code layers. That limitation cannot be removed easily, because it is built into the PM core design quite fundamentally. However, this series seems to be about controlling power resources represented by power domain objects rather than about PM operations. In ACPI there is a power resource concept which seems to be quite similar to this, so it is not entirely new. :-) Of course, question is whether or not to extend genpd this way and I'm not really sure. I actually probably wouldn't do that, because poweron/poweroff operations used by genpd can be implemeted in terms of lower-level power resource control and I don't see the reason for mixing the two in one framework. > However, we currently know about at least two different SoCs that need > this. Perhaps we can extend the below list to justify adding a new > framework/APIs. Something along the lines what you propose in $subject > patchset. > > 1) Nvidia; to solve the USB super-speed host/device problem. > 2) QCOM, which has pointed to several cases where the PM topology is > laid out like devices having two PM domains.. > 3?) I don't fully remember - but I think Geert also pointed to some > examples where a device could reside in a clock domain but also in > power domain for a Renesas SoC!? > 4) ? > > Moreover, perhaps this could also be useful for SoCs using ACPI? No, it couldn't. At least not in general. Thanks, Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rafael@kernel.org> To: Ulf Hansson <ulf.hansson@linaro.org> Cc: Jon Hunter <jonathanh@nvidia.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Kevin Hilman <khilman@kernel.org>, Geert Uytterhoeven <geert@linux-m68k.org>, Rajendra Nayak <rnayak@codeaurora.org>, Stanimir Varbanov <stanimir.varbanov@linaro.org>, Stephen Boyd <sboyd@codeaurora.org>, Marek Szyprowski <m.szyprowski@samsung.com>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org> Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains Date: Tue, 25 Apr 2017 23:17:51 +0200 [thread overview] Message-ID: <CAJZ5v0gMzN_zfC_2nnRtYFyFon3-_mnioQhNbDP0wsr91RnagA@mail.gmail.com> (raw) In-Reply-To: <CAPDyKFoJ58pwGz2U90ob8a8cY=hEbE-wLBHZ0BBzqPoLW_wgGA@mail.gmail.com> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 25 April 2017 at 13:13, Jon Hunter <jonathanh@nvidia.com> wrote: >> >> On 28/03/17 15:13, Jon Hunter wrote: >>> The current generic PM domain framework (GenDP) only allows a single >>> PM domain to be associated with a given device. There are several >>> use-cases for various system-on-chip devices where it is necessary for >>> a PM domain consumer to control more than one PM domain where the PM >>> domains: >>> i). Do not conform to a parent-child relationship so are not nested >>> ii). May not be powered on and off at the same time so need independent >>> control. >>> >>> The solution proposed in this RFC is to allow consumers to explictly >>> control PM domains, by getting a handle to a PM domain and explicitly >>> making calls to power on and off the PM domain. Note that referencing >>> counting is used to ensure that a PM domain shared between consumers >>> is not powered off incorrectly. >>> >>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>> controllers) is an example of a consumer that needs to control more than >>> one PM domain because the logic is partitioned across 3 PM domains which >>> are: >>> - XUSBA: Superspeed logic (for USB 3.0) >>> - XUSBB: Device controller >>> - XUSBC: Host controller >>> >>> These power domains are not nested and can be powered-up and down >>> independently of one another. In practice different scenarios require >>> different combinations of the power domains, for example: >>> - Superspeed host: XUSBA and XUSBC >>> - Superspeed device: XUSBA and XUSBB >>> >>> Although it could be possible to logically nest both the XUSBB and XUSBC >>> domains under the XUSBA, superspeed may not always be used/required and >>> so this would keep it on unnecessarily. >>> >>> Given that Tegra uses device-tree for describing the hardware, it would >>> be ideal that the device-tree 'power-domains' property for generic PM >>> domains could be extended to allow more than one PM domain to be >>> specified. For example, define the following the Tegra210 xHCI device ... >>> >>> usb@70090000 { >>> compatible = "nvidia,tegra210-xusb"; >>> ... >>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>> power-domain-names = "host", "superspeed"; >>> }; >>> >>> This RFC extends the generic PM domain framework to allow a device to >>> define more than one PM domain in the device-tree 'power-domains' >>> property. If there is more than one then the assumption is that these >>> PM domains will be controlled explicitly by the consumer and the device >>> will not be automatically bound to any PM domain. >> >> Any more comments/inputs on this? I can address Rajendra's feedback, but >> before I did I wanted to see if this is along the right lines or not? > > I discussed this with Rafael at the OSPM summit in Pisa a couple of > weeks ago. Apologize for the delay in providing additional feedback. > > First, whether the problem is really rare, perhaps adding a new > API/framework can't be justified - then it may be better to add some > kind of aggregation layer on top of the current PM domain > infrastructure (something along the first attempt you made for genpd). > That was kind of Rafael's thoughts (Rafael, please correct me if I am > wrong). We were talking about the original idea behind the pm_domain pointer concept, which was about adding a set of PM operations above the bus type/class layer, which could be used for intercepting bus-type PM operations and providing some common handling above them. This is still relevant IMO. The basic observation here is that the PM core takes only one set of PM operation per device into account and therefore, in every stage of system suspend, for example, the callback invoked by it has to take care of all actions that need to be carried out for the given device, possibly by invoking callbacks from other code layers. That limitation cannot be removed easily, because it is built into the PM core design quite fundamentally. However, this series seems to be about controlling power resources represented by power domain objects rather than about PM operations. In ACPI there is a power resource concept which seems to be quite similar to this, so it is not entirely new. :-) Of course, question is whether or not to extend genpd this way and I'm not really sure. I actually probably wouldn't do that, because poweron/poweroff operations used by genpd can be implemeted in terms of lower-level power resource control and I don't see the reason for mixing the two in one framework. > However, we currently know about at least two different SoCs that need > this. Perhaps we can extend the below list to justify adding a new > framework/APIs. Something along the lines what you propose in $subject > patchset. > > 1) Nvidia; to solve the USB super-speed host/device problem. > 2) QCOM, which has pointed to several cases where the PM topology is > laid out like devices having two PM domains.. > 3?) I don't fully remember - but I think Geert also pointed to some > examples where a device could reside in a clock domain but also in > power domain for a Renesas SoC!? > 4) ? > > Moreover, perhaps this could also be useful for SoCs using ACPI? No, it couldn't. At least not in general. Thanks, Rafael
next prev parent reply other threads:[~2017-04-25 21:17 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-28 14:13 [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains Jon Hunter 2017-03-28 14:13 ` Jon Hunter 2017-03-28 14:14 ` [RFC PATCH 1/4] PM / Domains: Prepare for supporting explicit PM domain control Jon Hunter 2017-03-28 14:14 ` Jon Hunter 2017-03-28 14:14 ` [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains Jon Hunter 2017-03-28 14:14 ` Jon Hunter [not found] ` <1490710443-27425-3-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-04-10 4:09 ` Rajendra Nayak 2017-04-10 4:09 ` Rajendra Nayak 2017-04-10 8:24 ` Jon Hunter 2017-04-10 8:24 ` Jon Hunter [not found] ` <3135e238-48a3-3693-bb59-63bf2a6d8d0e-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-04-10 10:02 ` Rajendra Nayak 2017-04-10 10:02 ` Rajendra Nayak 2017-04-10 19:48 ` Jon Hunter 2017-04-10 19:48 ` Jon Hunter 2017-03-28 14:14 ` [RFC PATCH 3/4] PM / Domains: Add OF helpers for getting " Jon Hunter 2017-03-28 14:14 ` Jon Hunter [not found] ` <1490710443-27425-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-03-28 14:14 ` [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple " Jon Hunter 2017-03-28 14:14 ` Jon Hunter 2017-04-10 4:12 ` Rajendra Nayak [not found] ` <3f96256d-0de5-26a2-e656-7912e06806ea-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-04-10 8:24 ` Jon Hunter 2017-04-10 8:24 ` Jon Hunter 2017-04-25 11:13 ` [RFC PATCH 0/4] PM / Domains: Add support for explicit control of " Jon Hunter 2017-04-25 11:13 ` Jon Hunter [not found] ` <d2e3ceaa-57e2-033d-ecd1-a3b2bd8ffa26-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-04-25 19:34 ` Ulf Hansson 2017-04-25 19:34 ` Ulf Hansson [not found] ` <CAPDyKFoJ58pwGz2U90ob8a8cY=hEbE-wLBHZ0BBzqPoLW_wgGA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-04-25 21:17 ` Rafael J. Wysocki [this message] 2017-04-25 21:17 ` Rafael J. Wysocki [not found] ` <CAJZ5v0gMzN_zfC_2nnRtYFyFon3-_mnioQhNbDP0wsr91RnagA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-05-02 10:10 ` Jon Hunter 2017-05-02 10:10 ` Jon Hunter [not found] ` <ffe13074-9113-0a20-0fa6-76d0209dadfc-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-05-02 21:51 ` Rafael J. Wysocki 2017-05-02 21:51 ` Rafael J. Wysocki 2017-05-03 8:12 ` Ulf Hansson [not found] ` <CAPDyKFokVKZfRAsEAB6ihx1FxW4JjarionyOwCATr3s+QW4aMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-05-03 8:32 ` Jon Hunter 2017-05-03 8:32 ` Jon Hunter 2017-05-03 8:32 ` Jon Hunter [not found] ` <b4e8fd34-e2f0-165d-aa22-32ba43a8dbed-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-05-03 13:43 ` Ulf Hansson 2017-05-03 13:43 ` Ulf Hansson [not found] ` <CAPDyKFo-hfwbrY+AEMt0=fMshiT-BWvYDvGkKGqquTdowUvWHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-05-03 14:57 ` Jon Hunter 2017-05-03 14:57 ` Jon Hunter 2017-05-03 17:12 ` Ulf Hansson 2017-05-04 8:44 ` Jon Hunter 2017-05-30 3:41 ` Rajendra Nayak [not found] ` <5fcfeda6-f95c-cdaa-73a5-5c7499a3f9f5-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2017-10-09 16:36 ` Todor Tomov 2017-10-09 16:36 ` Todor Tomov [not found] ` <72397ec8-d169-c5b1-2120-459031b35d48-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2017-10-10 9:13 ` Jon Hunter 2017-10-10 9:13 ` Jon Hunter [not found] ` <1832647.f77WMLkdQb-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org> 2017-05-03 8:12 ` Jon Hunter 2017-05-03 8:12 ` Jon Hunter 2017-04-26 8:06 ` Geert Uytterhoeven [not found] ` <CAMuHMdWvS6_Zf1nn1=zVLb1qNChyk+B6BDZsK9P9oKRBEpPKMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-04-26 9:04 ` Ulf Hansson 2017-04-26 9:04 ` Ulf Hansson [not found] ` <CAPDyKFqqZPXpxCTDy079QeiAorLVrXZssQ5SvXLWa3oab21b5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-04-26 9:17 ` Geert Uytterhoeven 2017-04-26 9:17 ` Geert Uytterhoeven [not found] ` <CAMuHMdWNnWdYop_U4BGznxDND3WK-V7hnCBbnPoUDzUHBBpgHA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-04-26 9:55 ` Ulf Hansson 2017-04-26 9:55 ` Ulf Hansson [not found] ` <CAPDyKFrg+L_U6ztzpUdQMuemXyPWvtWVt06GumXa1MoTjJesWg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-05-03 6:43 ` Geert Uytterhoeven 2017-05-03 6:43 ` Geert Uytterhoeven [not found] ` <CAMuHMdXr6-pKb0wRfs0_HhNp75ikGOtd-n2mEY-fvVJhaU5idg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-05-03 8:54 ` Geert Uytterhoeven 2017-05-03 8:54 ` Geert Uytterhoeven
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=CAJZ5v0gMzN_zfC_2nnRtYFyFon3-_mnioQhNbDP0wsr91RnagA@mail.gmail.com \ --to=rafael-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \ --cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \ --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \ --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \ --cc=rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@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.