Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1523448

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

From "Rafael J. Wysocki" <rafael@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
Date 2016-11-16 14:00 +0100
Message-ID <sE7YJ-2Un-1@gated-at.bofh.it> (permalink)
References (2 earlier) <sqGMF-zG-21@gated-at.bofh.it> <sqJrb-2eB-11@gated-at.bofh.it> <sr1xM-4Ta-35@gated-at.bofh.it> <szrbH-52q-25@gated-at.bofh.it> <sE5WV-1Gs-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> Hi Kevin, Ulf,
>
> On 03/11/16 14:20, Jon Hunter wrote:
>>
>> On 11/10/16 10:15, Jon Hunter wrote:
>>
>> ...
>>
>>>>>> Second, another way of seeing this is: Depending on the current
>>>>>> runtime selected configuration you need to re-configure the PM domain
>>>>>> topology - but the device would still remain in the same PM domain.
>>>>>>
>>>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>>>> the selected configuration. Would that better reflect the HW?
>>>>>
>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>>>> like to get to ...
>>>>>
>>>>>         usb@70090000 {
>>>>>                 compatible = "nvidia,tegra210-xusb";
>>>>>                 ...
>>>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>         };
>>>>
>>>> So, is this really is a proper description of the HW? Isn't it so,
>>>> that the usb device always resides in one and the same PM domain?
>>>
>>> I guess technically, the usbhost controller resides in one partition and
>>> the super-speed logic in another. So could the usbhost domain be the
>>> primary? Possibly, but the device cannot be probed without both enabled.
>>>
>>>> Now, depending on the selected speed mode (superspeed) additional
>>>> logic may needs to be powered on and configured for the usb device to
>>>> work?
>>>> Perhaps, one could consider those additional logics as a master/parent
>>>> PM domain for the usb device's PM domain?
>>>>
>>>> Or this is not how the HW works? :-)
>>>
>>> It might be possible for this case, but to be honest, the more I think
>>> about this, I do wonder if we need to be able to make the framework a
>>> lot more flexible for devices that need multiple power-domains. In other
>>> words, for devices that use multiple domains allow them to control them
>>> similarly to what we do for regulators or clocks. So if there is more
>>> than one defined, then the genpd core will not bind the device to the
>>> pm-domain and let the driver handle it. This way if you do need more
>>> granular control of the pm-domains in the driver you can do whatever you
>>> need to.
>>>
>>> I know that Rajendra (CC'ed) was looking into whether he had a need to
>>> control multiple power-domains individually from within the context of a
>>> single device driver.
>>
>> So Rajendra commented to say that he does not see a need for individual
>> control of power-domains for now, but a need for specifying multiple.
>>
>> One simple option would be to allow users to specify multiple and have
>> the genpd core effectively ignore such devices and leave it to the
>> driver to configure manually. I have been able to do this for XUSB by
>> dynamically adding power-domains to the device.
>>
>> Let me know if you have any more thoughts on how we can do this.
>
> Any more thoughts on this? Seems that there are a few others that would
> be interested in supporting multiple domains for a device.

There is a design limitation to that, however.

The PM domain concept really is about intercepting the flow of PM
callbacks for a device in order to carry out additional operations,
not covered by the bus type or driver.  That's why there is only one
set of PM domain callbacks per device and I don't quite see how and
why it would be useful to add more of them in there.

Thanks,
Rafael

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-16 11:50 +0100
  Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains "Rafael J. Wysocki" <rafael@kernel.org> - 2016-11-16 14:00 +0100
    Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-22 12:20 +0100
      Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Ulf Hansson <ulf.hansson@linaro.org> - 2016-11-22 14:40 +0100
        Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-22 15:30 +0100
      Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Kevin Hilman <khilman@baylibre.com> - 2016-11-22 19:30 +0100
        Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-22 19:50 +0100
          Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Stephen Boyd <sboyd@codeaurora.org> - 2016-11-24 03:40 +0100
        Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains "Rafael J. Wysocki" <rafael@kernel.org> - 2016-11-22 23:40 +0100
          Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains Jon Hunter <jonathanh@nvidia.com> - 2016-11-23 10:30 +0100
            Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that  require multiple domains "Rafael J. Wysocki" <rafael@kernel.org> - 2016-11-23 14:20 +0100

csiph-web