[lkml]   [2016]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
On Wed, Nov 23, 2016 at 10:29 AM, Jon Hunter <> wrote:
> On 22/11/16 21:55, Rafael J. Wysocki wrote:
>> On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <> wrote:
>>> Jon Hunter <> writes:
>>>> On 16/11/16 12:53, Rafael J. Wysocki wrote:
>>>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <> 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.
>>> @Rafael: Re: why it would be useful...
>>> Many ARM SoCs have devices that have independent power rails for the
>>> memory and the logic of an IP block. For example, while powering off
>>> the logic you could keep the memory at a retention voltage, so you'd
>>> want to treat those power domains separately.
>>> Today, in order to model this, you'd have to create another (dummy)
>>> device, just for the memory and put it in its own domain so the two
>>> could be controlled separately.
>> Perhaps if you want to use genpd for that. :-)
>> Let me rephrase, though. I don't see why and how it would be useful
>> to intercept the flow of PM callbacks for a given device more than
>> once.
> In this RFC, all I was proposing is that we create a dummy pm-domain
> that is a child of the actual pm-domains it uses and this new dummy
> pm-domain is associated with the device. Hence, you are still only
> intercepting the flow of PM callback once even with this approach. I am
> just using the parent-child relationship to ensure that all require
> pm-domains are turned on thats all. Sorry if I am still missing your point!

No, you aren't, thanks for explaining that!


 \ /
  Last update: 2016-11-23 14:16    [W:0.082 / U:1.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site