On 16/11/16 12:53, Rafael J. Wysocki wrote:
> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@xxxxxxxxxx> 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.
Sorry for the delay.
We do, however, support the nesting of power-domains to allow more than
one power-domain to be controlled for a device. For the current
implementations that use nested power-domains, I am not sure if the
power-domains are truly nested or just describing a relationship between
power-domains.
Nesting power-domains could also work for the Tegra XHCI device.
However, I don't wish to statically nest the power-domains in
device-tree where they are defined so they are always nested, because
this may not be always necessary. However, I would rather the client of
the power-domains specify which power-domains they require and
dynamically nested the power-domains at runtime. This is slightly
different to what I proposed in this RFC, but it is not really beyond
the bounds of what we support today IMO. What is missing is a means to
do this dynamically and not statically.
By the way, I am not sure if you are suggesting that for devices that
may need multiple power-domains we should architect the driver
differently and split it up in some way such that we have a power-domain
per device. But for the case of the Tegra XHCI it is quite complex
because the driver loads firmware which runs on a micro-controller and
we need to manage the various power-domains that are used.
Cheers
Jon
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
