Jon Hunter [off-list ref] writes:

On 16/11/16 12:53, Rafael J. Wysocki wrote:

quoted

On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter [off-list ref] wrote:

quoted

Hi Kevin, Ulf,

On 03/11/16 14:20, Jon Hunter wrote:

quoted

On 11/10/16 10:15, Jon Hunter wrote:

...

quoted

quoted

quoted

quoted

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.

quoted

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.

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.

@Jon: Do you think the nesting could work to handle the above case too?

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.

And, that's not describing the hardware very accurately either, IIUC

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.

IMO, constructing a network of new struct devices just to workaround
limitations in the framework doesn't sound quite right either.

Kevin