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

[Jon Hunter]

Hi Rajendra,

On 15/03/17 03:47, Nayak, Rajendra wrote:
> Hey Jon,
> 
 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>>
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a
>> device,
>> +* then these need to be manually controlled by the
>> device
>> +* driver because the genpd core cannot bind a device
>> with
>> +* more than one PM domain.
>> +*/
>> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n",
>> ret);
>> +   return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the
>> pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
> 
> These would also need some kind of usecounting I guess, since genpd
> otherwise relies on runtime PM to do the usecounting.

Yes exactly.

> This overall seems like a reasonable approach to solve the problem we
> have. While we discussed this approach at connect, we thought it would
> be a good idea to bring out some RFC on these lines to get the
> discussion going. Do you think you would be able to work on some quick
> RFC around these lines, else if you think you would be busy in the near
> term I can help with hacking up the changes as well.

Yes I plan too. I will let you know if I get side tracked on something else.

Cheers!
Jon

-- 
nvpublic

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

[Jon Hunter]

Hi Rajendra,

On 15/03/17 03:47, Nayak, Rajendra wrote:
> Hey Jon,
> 
 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>>
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a
>> device,
>> +* then these need to be manually controlled by the
>> device
>> +* driver because the genpd core cannot bind a device
>> with
>> +* more than one PM domain.
>> +*/
>> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n",
>> ret);
>> +   return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the
>> pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
> 
> These would also need some kind of usecounting I guess, since genpd
> otherwise relies on runtime PM to do the usecounting.

Yes exactly.

> This overall seems like a reasonable approach to solve the problem we
> have. While we discussed this approach at connect, we thought it would
> be a good idea to bring out some RFC on these lines to get the
> discussion going. Do you think you would be able to work on some quick
> RFC around these lines, else if you think you would be busy in the near
> term I can help with hacking up the changes as well.

Yes I plan too. I will let you know if I get side tracked on something else.

Cheers!
Jon

-- 
nvpublic

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

[Jon Hunter]

On 13/03/17 14:42, Ulf Hansson wrote:
> On 13 March 2017 at 15:09, Jon Hunter  wrote:
>> Hi Ulf,
>>
>> On 13/03/17 11:45, Ulf Hansson wrote:
>>> +Björn
>>>
>>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
 Hi Rafael, Kevin, Ulf,

 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
> 
> This could work. However, let's involve DT maintainers to make sure we
> get their input to this. Perhaps they prefer a different approach.

No problem. I should point out the above is for the #power-domain-cells
= <0> case.

>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a device,
>> +* then these need to be manually controlled by the device
>> +* driver because the genpd core cannot bind a device with
>> +* more than one PM domain.
>> +*/
>> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
>> +   return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
>>
>> Are there any potential pitfalls of the above?
> 
> So if I understand correctly, you would like to extend genpd with some
> new APIs. It's worth a try, however my main worries are these:
> 
> 1) These new API must not be allowed to be abused.
> I have seen that before as when people try to handle some corner
> cases, I don't want to that to happen again. To avoid that, perhaps we
> should continue the re-structuring and thus move structures/datas that
> are currently public, to be internal to genpd. To get a clean
> interface.

OK, fair enough. Any in particular you are concerned about?

> 2) I wouldn't be surprised if we run into some tricky corner cases, as
> we get a mixture of devices handled by runtime PM and in some other
> cases via new APIs. Perhaps that can be sorted out!?

Right that is a concern, however, I think that in the long-term we would
be better off with the power-domains being controlled by the same
underlying code as opposed to something different.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

On 13/03/17 14:42, Ulf Hansson wrote:
> On 13 March 2017 at 15:09, Jon Hunter  wrote:
>> Hi Ulf,
>>
>> On 13/03/17 11:45, Ulf Hansson wrote:
>>> +Björn
>>>
>>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
 Hi Rafael, Kevin, Ulf,

 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
> 
> This could work. However, let's involve DT maintainers to make sure we
> get their input to this. Perhaps they prefer a different approach.

No problem. I should point out the above is for the #power-domain-cells
= <0> case.

>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a device,
>> +* then these need to be manually controlled by the device
>> +* driver because the genpd core cannot bind a device with
>> +* more than one PM domain.
>> +*/
>> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
>> +   return 0;
>> }
>>
>> Then add some new public APIs for getting and controlling the pm-domains ...
>>
>> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
>> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>>
>> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
>> void pm_genpd_put(struct generic_pm_domain *pd);
>> int pm_genpd_power_on(struct generic_pm_domain *pd);
>> int pm_genpd_power_off(struct generic_pm_domain *pd);
>> - Power on/off APIs would be synchronous types
>>
>> Are there any potential pitfalls of the above?
> 
> So if I understand correctly, you would like to extend genpd with some
> new APIs. It's worth a try, however my main worries are these:
> 
> 1) These new API must not be allowed to be abused.
> I have seen that before as when people try to handle some corner
> cases, I don't want to that to happen again. To avoid that, perhaps we
> should continue the re-structuring and thus move structures/datas that
> are currently public, to be internal to genpd. To get a clean
> interface.

OK, fair enough. Any in particular you are concerned about?

> 2) I wouldn't be surprised if we run into some tricky corner cases, as
> we get a mixture of devices handled by runtime PM and in some other
> cases via new APIs. Perhaps that can be sorted out!?

Right that is a concern, however, I think that in the long-term we would
be better off with the power-domains being controlled by the same
underlying code as opposed to something different.

Cheers
Jon

-- 
nvpublic

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

[Nayak, Rajendra]

Hey Jon,


Looks like there is still some interest/needs in/for this. Any thoughts
on how we can move this forward?


At the Linaro Connect last week, I was talking to Björn, Rajendra and
Stephen more about these related issues.

It definitely seems like we need to progress with this somehow,
meaning we need a solution for being able to associate a device with
more than one PM domain. In that context, I don't think genpd based on
its current design, is a good fit to solve the problem.

Instead I think we need something entirely new (perhaps some code can
be borrowed from genpd), which is more similar to the clock/regulator
framework. In other words, what you also were suggesting in a earlier
reply.
In this way, the driver/subsystem gains full flexibility of managing
its device's PM domains, which seems like the best future-proof
solution.


I agree, I think that that would give us the most flexibility to handle
whatever scenario. However, I was thinking that we could still use the
genpd core to register pm-domains with and control. My thought was to
allow devices to have a bindings with multiple pm-domains ...

dev-xyz {
...
power-domains = <>, <>;
};

Then in the genpd core we do having something like ...

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..d1ae6ddf4903 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
"samsung,power-domain", 0);
if (!pd_args.np)
return -ENOENT;
+   } else if (ret > 1) {
+   /*
+* If there are more than one PM domain defined for a device,
+* then these need to be manually controlled by the device
+* driver because the genpd core cannot bind a device with
+* more than one PM domain.
+*/
+   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
+   return 0;
}

Then add some new public APIs for getting and controlling the pm-domains ...

struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
- Use 'dev->of_node' to look-up pm-domain if populated, else uses name.

struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
void pm_genpd_put(struct generic_pm_domain *pd);
int pm_genpd_power_on(struct generic_pm_domain *pd);
int pm_genpd_power_off(struct generic_pm_domain *pd);
- Power on/off APIs would be synchronous types


These would also need some kind of usecounting I guess, since genpd
otherwise relies on runtime PM to do the usecounting.

This overall seems like a reasonable approach to solve the problem we
have. While we discussed this approach at connect, we thought it would
be a good idea to bring out some RFC on these lines to get the
discussion going. Do you think you would be able to work on some quick 
RFC around these lines, else if you think you would be busy in the near 
term I can help with hacking up the changes as well.


regards,
Rajendra



Are there any potential pitfalls of the above?

Cheers
Jon

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

[Nayak, Rajendra]

Hey Jon,


Looks like there is still some interest/needs in/for this. Any thoughts
on how we can move this forward?


At the Linaro Connect last week, I was talking to Björn, Rajendra and
Stephen more about these related issues.

It definitely seems like we need to progress with this somehow,
meaning we need a solution for being able to associate a device with
more than one PM domain. In that context, I don't think genpd based on
its current design, is a good fit to solve the problem.

Instead I think we need something entirely new (perhaps some code can
be borrowed from genpd), which is more similar to the clock/regulator
framework. In other words, what you also were suggesting in a earlier
reply.
In this way, the driver/subsystem gains full flexibility of managing
its device's PM domains, which seems like the best future-proof
solution.


I agree, I think that that would give us the most flexibility to handle
whatever scenario. However, I was thinking that we could still use the
genpd core to register pm-domains with and control. My thought was to
allow devices to have a bindings with multiple pm-domains ...

dev-xyz {
...
power-domains = <>, <>;
};

Then in the genpd core we do having something like ...

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..d1ae6ddf4903 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
"samsung,power-domain", 0);
if (!pd_args.np)
return -ENOENT;
+   } else if (ret > 1) {
+   /*
+* If there are more than one PM domain defined for a device,
+* then these need to be manually controlled by the device
+* driver because the genpd core cannot bind a device with
+* more than one PM domain.
+*/
+   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
+   return 0;
}

Then add some new public APIs for getting and controlling the pm-domains ...

struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
- Use 'dev->of_node' to look-up pm-domain if populated, else uses name.

struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
void pm_genpd_put(struct generic_pm_domain *pd);
int pm_genpd_power_on(struct generic_pm_domain *pd);
int pm_genpd_power_off(struct generic_pm_domain *pd);
- Power on/off APIs would be synchronous types


These would also need some kind of usecounting I guess, since genpd
otherwise relies on runtime PM to do the usecounting.

This overall seems like a reasonable approach to solve the problem we
have. While we discussed this approach at connect, we thought it would
be a good idea to bring out some RFC on these lines to get the
discussion going. Do you think you would be able to work on some quick 
RFC around these lines, else if you think you would be busy in the near 
term I can help with hacking up the changes as well.


regards,
Rajendra



Are there any potential pitfalls of the above?

Cheers
Jon

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

[Jon Hunter]

Hi Geert,

On 13/03/17 14:38, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter  wrote:
>> On 13/03/17 14:19, Geert Uytterhoeven wrote:
>>> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
 On 13/03/17 11:45, Ulf Hansson wrote:
> +Björn
>
> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>> Looks like there is still some interest/needs in/for this. Any thoughts
>> on how we can move this forward?
>
> At the Linaro Connect last week, I was talking to Björn, Rajendra and
> Stephen more about these related issues.
>
> It definitely seems like we need to progress with this somehow,
> meaning we need a solution for being able to associate a device with
> more than one PM domain. In that context, I don't think genpd based on
> its current design, is a good fit to solve the problem.
>
> Instead I think we need something entirely new (perhaps some code can
> be borrowed from genpd), which is more similar to the clock/regulator
> framework. In other words, what you also were suggesting in a earlier
> reply.
> In this way, the driver/subsystem gains full flexibility of managing
> its device's PM domains, which seems like the best future-proof
> solution.

 I agree, I think that that would give us the most flexibility to handle
 whatever scenario. However, I was thinking that we could still use the
 genpd core to register pm-domains with and control. My thought was to
 allow devices to have a bindings with multiple pm-domains ...

 dev-xyz {
 ...
 power-domains = <>, <>;
 };

 Then in the genpd core we do having something like ...

 diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
 index e697dec9d25b..d1ae6ddf4903 100644
 --- a/drivers/base/power/domain.c
 +++ b/drivers/base/power/domain.c
 @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
 "samsung,power-domain", 0);
 if (!pd_args.np)
 return -ENOENT;
 +   } else if (ret > 1) {
 +   /*
 +* If there are more than one PM domain defined for a 
 device,
 +* then these need to be manually controlled by the device
 +* driver because the genpd core cannot bind a device with
>>>
>>> Which device driver?
>>> The driver for the device that belongs to multiple PM domains?
>>
>> Yes, exactly. So maybe I would need to say ... "manually controlled by
>> the driver for *this* device ..."
> 
> That looks a bit cumbersome to me.
> 
> Power (and clock) domains are platform features.  Any IP core may show up
> in a new SoC, and suddenly have become part of one or more PM Domains.
> Having to handle that in each individual driver will cause lots of churn.
> Especially as the multiple PM Domains a device may belong to may be
> fairly orthogonal to each other.

Yes that's true. However, in order to make this work for everyone and
have a generic solution I am not sure how that can be avoided. If there
are cases where devices require multiple PM domains but the usage is
quite simple (ie. all on when device in use and all off when device is
not in use), I could see the APIs I proposed being extended to include
some _bulk() versions like we have for regulators.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

Hi Geert,

On 13/03/17 14:38, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter  wrote:
>> On 13/03/17 14:19, Geert Uytterhoeven wrote:
>>> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
 On 13/03/17 11:45, Ulf Hansson wrote:
> +Björn
>
> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>> Looks like there is still some interest/needs in/for this. Any thoughts
>> on how we can move this forward?
>
> At the Linaro Connect last week, I was talking to Björn, Rajendra and
> Stephen more about these related issues.
>
> It definitely seems like we need to progress with this somehow,
> meaning we need a solution for being able to associate a device with
> more than one PM domain. In that context, I don't think genpd based on
> its current design, is a good fit to solve the problem.
>
> Instead I think we need something entirely new (perhaps some code can
> be borrowed from genpd), which is more similar to the clock/regulator
> framework. In other words, what you also were suggesting in a earlier
> reply.
> In this way, the driver/subsystem gains full flexibility of managing
> its device's PM domains, which seems like the best future-proof
> solution.

 I agree, I think that that would give us the most flexibility to handle
 whatever scenario. However, I was thinking that we could still use the
 genpd core to register pm-domains with and control. My thought was to
 allow devices to have a bindings with multiple pm-domains ...

 dev-xyz {
 ...
 power-domains = <>, <>;
 };

 Then in the genpd core we do having something like ...

 diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
 index e697dec9d25b..d1ae6ddf4903 100644
 --- a/drivers/base/power/domain.c
 +++ b/drivers/base/power/domain.c
 @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
 "samsung,power-domain", 0);
 if (!pd_args.np)
 return -ENOENT;
 +   } else if (ret > 1) {
 +   /*
 +* If there are more than one PM domain defined for a 
 device,
 +* then these need to be manually controlled by the device
 +* driver because the genpd core cannot bind a device with
>>>
>>> Which device driver?
>>> The driver for the device that belongs to multiple PM domains?
>>
>> Yes, exactly. So maybe I would need to say ... "manually controlled by
>> the driver for *this* device ..."
> 
> That looks a bit cumbersome to me.
> 
> Power (and clock) domains are platform features.  Any IP core may show up
> in a new SoC, and suddenly have become part of one or more PM Domains.
> Having to handle that in each individual driver will cause lots of churn.
> Especially as the multiple PM Domains a device may belong to may be
> fairly orthogonal to each other.

Yes that's true. However, in order to make this work for everyone and
have a generic solution I am not sure how that can be avoided. If there
are cases where devices require multiple PM domains but the usage is
quite simple (ie. all on when device in use and all off when device is
not in use), I could see the APIs I proposed being extended to include
some _bulk() versions like we have for regulators.

Cheers
Jon

-- 
nvpublic

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

[Ulf Hansson]

On 13 March 2017 at 15:09, Jon Hunter  wrote:
> Hi Ulf,
>
> On 13/03/17 11:45, Ulf Hansson wrote:
>> +Björn
>>
>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>>> Hi Rafael, Kevin, Ulf,
>>>
>>> Looks like there is still some interest/needs in/for this. Any thoughts
>>> on how we can move this forward?
>>
>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>> Stephen more about these related issues.
>>
>> It definitely seems like we need to progress with this somehow,
>> meaning we need a solution for being able to associate a device with
>> more than one PM domain. In that context, I don't think genpd based on
>> its current design, is a good fit to solve the problem.
>>
>> Instead I think we need something entirely new (perhaps some code can
>> be borrowed from genpd), which is more similar to the clock/regulator
>> framework. In other words, what you also were suggesting in a earlier
>> reply.
>> In this way, the driver/subsystem gains full flexibility of managing
>> its device's PM domains, which seems like the best future-proof
>> solution.
>
> I agree, I think that that would give us the most flexibility to handle
> whatever scenario. However, I was thinking that we could still use the
> genpd core to register pm-domains with and control. My thought was to
> allow devices to have a bindings with multiple pm-domains ...
>
> dev-xyz {
> ...
> power-domains = <>, <>;
> };

This could work. However, let's involve DT maintainers to make sure we
get their input to this. Perhaps they prefer a different approach.

>
> Then in the genpd core we do having something like ...
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e697dec9d25b..d1ae6ddf4903 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
> "samsung,power-domain", 0);
> if (!pd_args.np)
> return -ENOENT;
> +   } else if (ret > 1) {
> +   /*
> +* If there are more than one PM domain defined for a device,
> +* then these need to be manually controlled by the device
> +* driver because the genpd core cannot bind a device with
> +* more than one PM domain.
> +*/
> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
> +   return 0;
> }
>
> Then add some new public APIs for getting and controlling the pm-domains ...
>
> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>
> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
> void pm_genpd_put(struct generic_pm_domain *pd);
> int pm_genpd_power_on(struct generic_pm_domain *pd);
> int pm_genpd_power_off(struct generic_pm_domain *pd);
> - Power on/off APIs would be synchronous types
>
> Are there any potential pitfalls of the above?

So if I understand correctly, you would like to extend genpd with some
new APIs. It's worth a try, however my main worries are these:

1) These new API must not be allowed to be abused.
I have seen that before as when people try to handle some corner
cases, I don't want to that to happen again. To avoid that, perhaps we
should continue the re-structuring and thus move structures/datas that
are currently public, to be internal to genpd. To get a clean
interface.

2) I wouldn't be surprised if we run into some tricky corner cases, as
we get a mixture of devices handled by runtime PM and in some other
cases via new APIs. Perhaps that can be sorted out!?

Kind regards
Uffe

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

[Ulf Hansson]

On 13 March 2017 at 15:09, Jon Hunter  wrote:
> Hi Ulf,
>
> On 13/03/17 11:45, Ulf Hansson wrote:
>> +Björn
>>
>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>>> Hi Rafael, Kevin, Ulf,
>>>
>>> Looks like there is still some interest/needs in/for this. Any thoughts
>>> on how we can move this forward?
>>
>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>> Stephen more about these related issues.
>>
>> It definitely seems like we need to progress with this somehow,
>> meaning we need a solution for being able to associate a device with
>> more than one PM domain. In that context, I don't think genpd based on
>> its current design, is a good fit to solve the problem.
>>
>> Instead I think we need something entirely new (perhaps some code can
>> be borrowed from genpd), which is more similar to the clock/regulator
>> framework. In other words, what you also were suggesting in a earlier
>> reply.
>> In this way, the driver/subsystem gains full flexibility of managing
>> its device's PM domains, which seems like the best future-proof
>> solution.
>
> I agree, I think that that would give us the most flexibility to handle
> whatever scenario. However, I was thinking that we could still use the
> genpd core to register pm-domains with and control. My thought was to
> allow devices to have a bindings with multiple pm-domains ...
>
> dev-xyz {
> ...
> power-domains = <>, <>;
> };

This could work. However, let's involve DT maintainers to make sure we
get their input to this. Perhaps they prefer a different approach.

>
> Then in the genpd core we do having something like ...
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e697dec9d25b..d1ae6ddf4903 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
> "samsung,power-domain", 0);
> if (!pd_args.np)
> return -ENOENT;
> +   } else if (ret > 1) {
> +   /*
> +* If there are more than one PM domain defined for a device,
> +* then these need to be manually controlled by the device
> +* driver because the genpd core cannot bind a device with
> +* more than one PM domain.
> +*/
> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
> +   return 0;
> }
>
> Then add some new public APIs for getting and controlling the pm-domains ...
>
> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>
> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
> void pm_genpd_put(struct generic_pm_domain *pd);
> int pm_genpd_power_on(struct generic_pm_domain *pd);
> int pm_genpd_power_off(struct generic_pm_domain *pd);
> - Power on/off APIs would be synchronous types
>
> Are there any potential pitfalls of the above?

So if I understand correctly, you would like to extend genpd with some
new APIs. It's worth a try, however my main worries are these:

1) These new API must not be allowed to be abused.
I have seen that before as when people try to handle some corner
cases, I don't want to that to happen again. To avoid that, perhaps we
should continue the re-structuring and thus move structures/datas that
are currently public, to be internal to genpd. To get a clean
interface.

2) I wouldn't be surprised if we run into some tricky corner cases, as
we get a mixture of devices handled by runtime PM and in some other
cases via new APIs. Perhaps that can be sorted out!?

Kind regards
Uffe

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

[Geert Uytterhoeven]

Hi Jon,

On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter  wrote:
> On 13/03/17 14:19, Geert Uytterhoeven wrote:
>> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
>>> On 13/03/17 11:45, Ulf Hansson wrote:
 +Björn

 On 13 March 2017 at 10:37, Jon Hunter  wrote:
> Looks like there is still some interest/needs in/for this. Any thoughts
> on how we can move this forward?

 At the Linaro Connect last week, I was talking to Björn, Rajendra and
 Stephen more about these related issues.

 It definitely seems like we need to progress with this somehow,
 meaning we need a solution for being able to associate a device with
 more than one PM domain. In that context, I don't think genpd based on
 its current design, is a good fit to solve the problem.

 Instead I think we need something entirely new (perhaps some code can
 be borrowed from genpd), which is more similar to the clock/regulator
 framework. In other words, what you also were suggesting in a earlier
 reply.
 In this way, the driver/subsystem gains full flexibility of managing
 its device's PM domains, which seems like the best future-proof
 solution.
>>>
>>> I agree, I think that that would give us the most flexibility to handle
>>> whatever scenario. However, I was thinking that we could still use the
>>> genpd core to register pm-domains with and control. My thought was to
>>> allow devices to have a bindings with multiple pm-domains ...
>>>
>>> dev-xyz {
>>> ...
>>> power-domains = <>, <>;
>>> };
>>>
>>> Then in the genpd core we do having something like ...
>>>
>>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>>> index e697dec9d25b..d1ae6ddf4903 100644
>>> --- a/drivers/base/power/domain.c
>>> +++ b/drivers/base/power/domain.c
>>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>>> "samsung,power-domain", 0);
>>> if (!pd_args.np)
>>> return -ENOENT;
>>> +   } else if (ret > 1) {
>>> +   /*
>>> +* If there are more than one PM domain defined for a 
>>> device,
>>> +* then these need to be manually controlled by the device
>>> +* driver because the genpd core cannot bind a device with
>>
>> Which device driver?
>> The driver for the device that belongs to multiple PM domains?
>
> Yes, exactly. So maybe I would need to say ... "manually controlled by
> the driver for *this* device ..."

That looks a bit cumbersome to me.

Power (and clock) domains are platform features.  Any IP core may show up
in a new SoC, and suddenly have become part of one or more PM Domains.
Having to handle that in each individual driver will cause lots of churn.
Especially as the multiple PM Domains a device may belong to may be
fairly orthogonal to each other.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Geert Uytterhoeven]

Hi Jon,

On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter  wrote:
> On 13/03/17 14:19, Geert Uytterhoeven wrote:
>> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
>>> On 13/03/17 11:45, Ulf Hansson wrote:
 +Björn

 On 13 March 2017 at 10:37, Jon Hunter  wrote:
> Looks like there is still some interest/needs in/for this. Any thoughts
> on how we can move this forward?

 At the Linaro Connect last week, I was talking to Björn, Rajendra and
 Stephen more about these related issues.

 It definitely seems like we need to progress with this somehow,
 meaning we need a solution for being able to associate a device with
 more than one PM domain. In that context, I don't think genpd based on
 its current design, is a good fit to solve the problem.

 Instead I think we need something entirely new (perhaps some code can
 be borrowed from genpd), which is more similar to the clock/regulator
 framework. In other words, what you also were suggesting in a earlier
 reply.
 In this way, the driver/subsystem gains full flexibility of managing
 its device's PM domains, which seems like the best future-proof
 solution.
>>>
>>> I agree, I think that that would give us the most flexibility to handle
>>> whatever scenario. However, I was thinking that we could still use the
>>> genpd core to register pm-domains with and control. My thought was to
>>> allow devices to have a bindings with multiple pm-domains ...
>>>
>>> dev-xyz {
>>> ...
>>> power-domains = <>, <>;
>>> };
>>>
>>> Then in the genpd core we do having something like ...
>>>
>>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>>> index e697dec9d25b..d1ae6ddf4903 100644
>>> --- a/drivers/base/power/domain.c
>>> +++ b/drivers/base/power/domain.c
>>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>>> "samsung,power-domain", 0);
>>> if (!pd_args.np)
>>> return -ENOENT;
>>> +   } else if (ret > 1) {
>>> +   /*
>>> +* If there are more than one PM domain defined for a 
>>> device,
>>> +* then these need to be manually controlled by the device
>>> +* driver because the genpd core cannot bind a device with
>>
>> Which device driver?
>> The driver for the device that belongs to multiple PM domains?
>
> Yes, exactly. So maybe I would need to say ... "manually controlled by
> the driver for *this* device ..."

That looks a bit cumbersome to me.

Power (and clock) domains are platform features.  Any IP core may show up
in a new SoC, and suddenly have become part of one or more PM Domains.
Having to handle that in each individual driver will cause lots of churn.
Especially as the multiple PM Domains a device may belong to may be
fairly orthogonal to each other.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Jon Hunter]

Hi Geert,

On 13/03/17 14:19, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
>> On 13/03/17 11:45, Ulf Hansson wrote:
>>> +Björn
>>>
>>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a device,
>> +* then these need to be manually controlled by the device
>> +* driver because the genpd core cannot bind a device with
> 
> Which device driver?
> The driver for the device that belongs to multiple PM domains?

Yes, exactly. So maybe I would need to say ... "manually controlled by
the driver for *this* device ..."

Jon

-- 
nvpublic

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

[Jon Hunter]

Hi Geert,

On 13/03/17 14:19, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
>> On 13/03/17 11:45, Ulf Hansson wrote:
>>> +Björn
>>>
>>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
 Looks like there is still some interest/needs in/for this. Any thoughts
 on how we can move this forward?
>>>
>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>>> Stephen more about these related issues.
>>>
>>> It definitely seems like we need to progress with this somehow,
>>> meaning we need a solution for being able to associate a device with
>>> more than one PM domain. In that context, I don't think genpd based on
>>> its current design, is a good fit to solve the problem.
>>>
>>> Instead I think we need something entirely new (perhaps some code can
>>> be borrowed from genpd), which is more similar to the clock/regulator
>>> framework. In other words, what you also were suggesting in a earlier
>>> reply.
>>> In this way, the driver/subsystem gains full flexibility of managing
>>> its device's PM domains, which seems like the best future-proof
>>> solution.
>>
>> I agree, I think that that would give us the most flexibility to handle
>> whatever scenario. However, I was thinking that we could still use the
>> genpd core to register pm-domains with and control. My thought was to
>> allow devices to have a bindings with multiple pm-domains ...
>>
>> dev-xyz {
>> ...
>> power-domains = <>, <>;
>> };
>>
>> Then in the genpd core we do having something like ...
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index e697dec9d25b..d1ae6ddf4903 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
>> "samsung,power-domain", 0);
>> if (!pd_args.np)
>> return -ENOENT;
>> +   } else if (ret > 1) {
>> +   /*
>> +* If there are more than one PM domain defined for a device,
>> +* then these need to be manually controlled by the device
>> +* driver because the genpd core cannot bind a device with
> 
> Which device driver?
> The driver for the device that belongs to multiple PM domains?

Yes, exactly. So maybe I would need to say ... "manually controlled by
the driver for *this* device ..."

Jon

-- 
nvpublic

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

[Geert Uytterhoeven]

Hi Jon,

On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
> On 13/03/17 11:45, Ulf Hansson wrote:
>> +Björn
>>
>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>>> Looks like there is still some interest/needs in/for this. Any thoughts
>>> on how we can move this forward?
>>
>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>> Stephen more about these related issues.
>>
>> It definitely seems like we need to progress with this somehow,
>> meaning we need a solution for being able to associate a device with
>> more than one PM domain. In that context, I don't think genpd based on
>> its current design, is a good fit to solve the problem.
>>
>> Instead I think we need something entirely new (perhaps some code can
>> be borrowed from genpd), which is more similar to the clock/regulator
>> framework. In other words, what you also were suggesting in a earlier
>> reply.
>> In this way, the driver/subsystem gains full flexibility of managing
>> its device's PM domains, which seems like the best future-proof
>> solution.
>
> I agree, I think that that would give us the most flexibility to handle
> whatever scenario. However, I was thinking that we could still use the
> genpd core to register pm-domains with and control. My thought was to
> allow devices to have a bindings with multiple pm-domains ...
>
> dev-xyz {
> ...
> power-domains = <>, <>;
> };
>
> Then in the genpd core we do having something like ...
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e697dec9d25b..d1ae6ddf4903 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
> "samsung,power-domain", 0);
> if (!pd_args.np)
> return -ENOENT;
> +   } else if (ret > 1) {
> +   /*
> +* If there are more than one PM domain defined for a device,
> +* then these need to be manually controlled by the device
> +* driver because the genpd core cannot bind a device with

Which device driver?
The driver for the device that belongs to multiple PM domains?
The PM domain providers?

> +* more than one PM domain.
> +*/
> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
> +   return 0;
> }
>
> Then add some new public APIs for getting and controlling the pm-domains ...
>
> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>
> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
> void pm_genpd_put(struct generic_pm_domain *pd);
> int pm_genpd_power_on(struct generic_pm_domain *pd);
> int pm_genpd_power_off(struct generic_pm_domain *pd);
> - Power on/off APIs would be synchronous types
>
> Are there any potential pitfalls of the above?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Geert Uytterhoeven]

Hi Jon,

On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter  wrote:
> On 13/03/17 11:45, Ulf Hansson wrote:
>> +Björn
>>
>> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>>> Looks like there is still some interest/needs in/for this. Any thoughts
>>> on how we can move this forward?
>>
>> At the Linaro Connect last week, I was talking to Björn, Rajendra and
>> Stephen more about these related issues.
>>
>> It definitely seems like we need to progress with this somehow,
>> meaning we need a solution for being able to associate a device with
>> more than one PM domain. In that context, I don't think genpd based on
>> its current design, is a good fit to solve the problem.
>>
>> Instead I think we need something entirely new (perhaps some code can
>> be borrowed from genpd), which is more similar to the clock/regulator
>> framework. In other words, what you also were suggesting in a earlier
>> reply.
>> In this way, the driver/subsystem gains full flexibility of managing
>> its device's PM domains, which seems like the best future-proof
>> solution.
>
> I agree, I think that that would give us the most flexibility to handle
> whatever scenario. However, I was thinking that we could still use the
> genpd core to register pm-domains with and control. My thought was to
> allow devices to have a bindings with multiple pm-domains ...
>
> dev-xyz {
> ...
> power-domains = <>, <>;
> };
>
> Then in the genpd core we do having something like ...
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e697dec9d25b..d1ae6ddf4903 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
> "samsung,power-domain", 0);
> if (!pd_args.np)
> return -ENOENT;
> +   } else if (ret > 1) {
> +   /*
> +* If there are more than one PM domain defined for a device,
> +* then these need to be manually controlled by the device
> +* driver because the genpd core cannot bind a device with

Which device driver?
The driver for the device that belongs to multiple PM domains?
The PM domain providers?

> +* more than one PM domain.
> +*/
> +   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
> +   return 0;
> }
>
> Then add some new public APIs for getting and controlling the pm-domains ...
>
> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name.
>
> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
> void pm_genpd_put(struct generic_pm_domain *pd);
> int pm_genpd_power_on(struct generic_pm_domain *pd);
> int pm_genpd_power_off(struct generic_pm_domain *pd);
> - Power on/off APIs would be synchronous types
>
> Are there any potential pitfalls of the above?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Jon Hunter]

Hi Ulf,

On 13/03/17 11:45, Ulf Hansson wrote:
> +Björn
> 
> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>> Hi Rafael, Kevin, Ulf,
>>
>> Looks like there is still some interest/needs in/for this. Any thoughts
>> on how we can move this forward?
> 
> At the Linaro Connect last week, I was talking to Björn, Rajendra and
> Stephen more about these related issues.
> 
> It definitely seems like we need to progress with this somehow,
> meaning we need a solution for being able to associate a device with
> more than one PM domain. In that context, I don't think genpd based on
> its current design, is a good fit to solve the problem.
> 
> Instead I think we need something entirely new (perhaps some code can
> be borrowed from genpd), which is more similar to the clock/regulator
> framework. In other words, what you also were suggesting in a earlier
> reply.
> In this way, the driver/subsystem gains full flexibility of managing
> its device's PM domains, which seems like the best future-proof
> solution.

I agree, I think that that would give us the most flexibility to handle
whatever scenario. However, I was thinking that we could still use the
genpd core to register pm-domains with and control. My thought was to
allow devices to have a bindings with multiple pm-domains ...

dev-xyz {
...
power-domains = <>, <>;
};

Then in the genpd core we do having something like ...

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..d1ae6ddf4903 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
"samsung,power-domain", 0);
if (!pd_args.np)
return -ENOENT;
+   } else if (ret > 1) {
+   /*
+* If there are more than one PM domain defined for a device,
+* then these need to be manually controlled by the device
+* driver because the genpd core cannot bind a device with
+* more than one PM domain.
+*/
+   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
+   return 0;
}

Then add some new public APIs for getting and controlling the pm-domains ...

struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
- Use 'dev->of_node' to look-up pm-domain if populated, else uses name.

struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
void pm_genpd_put(struct generic_pm_domain *pd);
int pm_genpd_power_on(struct generic_pm_domain *pd);
int pm_genpd_power_off(struct generic_pm_domain *pd);
- Power on/off APIs would be synchronous types

Are there any potential pitfalls of the above?

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

Hi Ulf,

On 13/03/17 11:45, Ulf Hansson wrote:
> +Björn
> 
> On 13 March 2017 at 10:37, Jon Hunter  wrote:
>> Hi Rafael, Kevin, Ulf,
>>
>> Looks like there is still some interest/needs in/for this. Any thoughts
>> on how we can move this forward?
> 
> At the Linaro Connect last week, I was talking to Björn, Rajendra and
> Stephen more about these related issues.
> 
> It definitely seems like we need to progress with this somehow,
> meaning we need a solution for being able to associate a device with
> more than one PM domain. In that context, I don't think genpd based on
> its current design, is a good fit to solve the problem.
> 
> Instead I think we need something entirely new (perhaps some code can
> be borrowed from genpd), which is more similar to the clock/regulator
> framework. In other words, what you also were suggesting in a earlier
> reply.
> In this way, the driver/subsystem gains full flexibility of managing
> its device's PM domains, which seems like the best future-proof
> solution.

I agree, I think that that would give us the most flexibility to handle
whatever scenario. However, I was thinking that we could still use the
genpd core to register pm-domains with and control. My thought was to
allow devices to have a bindings with multiple pm-domains ...

dev-xyz {
...
power-domains = <>, <>;
};

Then in the genpd core we do having something like ...

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..d1ae6ddf4903 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev)
"samsung,power-domain", 0);
if (!pd_args.np)
return -ENOENT;
+   } else if (ret > 1) {
+   /*
+* If there are more than one PM domain defined for a device,
+* then these need to be manually controlled by the device
+* driver because the genpd core cannot bind a device with
+* more than one PM domain.
+*/
+   dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret);
+   return 0;
}

Then add some new public APIs for getting and controlling the pm-domains ...

struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name);
- Use 'dev->of_node' to look-up pm-domain if populated, else uses name.

struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index);
void pm_genpd_put(struct generic_pm_domain *pd);
int pm_genpd_power_on(struct generic_pm_domain *pd);
int pm_genpd_power_off(struct generic_pm_domain *pd);
- Power on/off APIs would be synchronous types

Are there any potential pitfalls of the above?

Cheers
Jon

-- 
nvpublic

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

[Ulf Hansson]

+Björn

On 13 March 2017 at 10:37, Jon Hunter  wrote:
> Hi Rafael, Kevin, Ulf,
>
> Looks like there is still some interest/needs in/for this. Any thoughts
> on how we can move this forward?

At the Linaro Connect last week, I was talking to Björn, Rajendra and
Stephen more about these related issues.

It definitely seems like we need to progress with this somehow,
meaning we need a solution for being able to associate a device with
more than one PM domain. In that context, I don't think genpd based on
its current design, is a good fit to solve the problem.

Instead I think we need something entirely new (perhaps some code can
be borrowed from genpd), which is more similar to the clock/regulator
framework. In other words, what you also were suggesting in a earlier
reply.
In this way, the driver/subsystem gains full flexibility of managing
its device's PM domains, which seems like the best future-proof
solution.

Kind regards
Uffe

>
> Cheers
> Jon
>
> On 28/02/17 15:29, Geert Uytterhoeven wrote:
>> Hi Jon,
>>
>> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter  wrote:
>>> On 20/09/16 11:28, Jon Hunter wrote:
 The Tegra124/210 XUSB subsystem (that consists of both host and device
 controllers) 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@7009 {
   compatible = "nvidia,tegra210-xusb";
   ...
   power-domains = <_xusbhost>, <_xusbss>;
   };

 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.
>>>
>>> I wanted to kick this thread again now in the new year and see if there
>>> is still some interest in pursuing this?
>>>
>>> There is still very much a need from a Tegra perspective. I have put all
>>> those who responded on TO.
>>>
>>> I know that a lot of time has passed since we discuss this and so if you
>>> are scratching your head wondering what I am harping on about,
>>> essentially with this RFC I was looking for a way to support devices
>>> that require multiple power domains where the domains do not have a
>>> parent-child relationship and so not are nested in anyway.
>>>
>>> If you need me to elaborate on the need for this, I am happy to do this.
>>> My take away from when we discussed this last year, was that there was a
>>> need for this.
>>
>> It definitely makes sense to me, as the "power-domains" DT binding is not
>> limited to plain "power areas", but may refer to clock domains, too
>> (cfr. the Linux "PM Domain" notion).
>>
>> For my (Renesas) use case, we have devices that are part of both a power
>> area and a clock domain. Currently this is handled by the power area driver
>> calling into the clock driver.
>>
>> Thanks!
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
>> ge...@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like 
>> that.
>> -- Linus Torvalds
>>
>
> --
> nvpublic

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

[Ulf Hansson]

+Björn

On 13 March 2017 at 10:37, Jon Hunter  wrote:
> Hi Rafael, Kevin, Ulf,
>
> Looks like there is still some interest/needs in/for this. Any thoughts
> on how we can move this forward?

At the Linaro Connect last week, I was talking to Björn, Rajendra and
Stephen more about these related issues.

It definitely seems like we need to progress with this somehow,
meaning we need a solution for being able to associate a device with
more than one PM domain. In that context, I don't think genpd based on
its current design, is a good fit to solve the problem.

Instead I think we need something entirely new (perhaps some code can
be borrowed from genpd), which is more similar to the clock/regulator
framework. In other words, what you also were suggesting in a earlier
reply.
In this way, the driver/subsystem gains full flexibility of managing
its device's PM domains, which seems like the best future-proof
solution.

Kind regards
Uffe

>
> Cheers
> Jon
>
> On 28/02/17 15:29, Geert Uytterhoeven wrote:
>> Hi Jon,
>>
>> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter  wrote:
>>> On 20/09/16 11:28, Jon Hunter wrote:
 The Tegra124/210 XUSB subsystem (that consists of both host and device
 controllers) 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@7009 {
   compatible = "nvidia,tegra210-xusb";
   ...
   power-domains = <_xusbhost>, <_xusbss>;
   };

 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.
>>>
>>> I wanted to kick this thread again now in the new year and see if there
>>> is still some interest in pursuing this?
>>>
>>> There is still very much a need from a Tegra perspective. I have put all
>>> those who responded on TO.
>>>
>>> I know that a lot of time has passed since we discuss this and so if you
>>> are scratching your head wondering what I am harping on about,
>>> essentially with this RFC I was looking for a way to support devices
>>> that require multiple power domains where the domains do not have a
>>> parent-child relationship and so not are nested in anyway.
>>>
>>> If you need me to elaborate on the need for this, I am happy to do this.
>>> My take away from when we discussed this last year, was that there was a
>>> need for this.
>>
>> It definitely makes sense to me, as the "power-domains" DT binding is not
>> limited to plain "power areas", but may refer to clock domains, too
>> (cfr. the Linux "PM Domain" notion).
>>
>> For my (Renesas) use case, we have devices that are part of both a power
>> area and a clock domain. Currently this is handled by the power area driver
>> calling into the clock driver.
>>
>> Thanks!
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
>> ge...@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like 
>> that.
>> -- Linus Torvalds
>>
>
> --
> nvpublic

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

[Jon Hunter]

Hi Rafael, Kevin, Ulf,

Looks like there is still some interest/needs in/for this. Any thoughts
on how we can move this forward?

Cheers
Jon

On 28/02/17 15:29, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter  wrote:
>> On 20/09/16 11:28, Jon Hunter wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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@7009 {
>>>   compatible = "nvidia,tegra210-xusb";
>>>   ...
>>>   power-domains = <_xusbhost>, <_xusbss>;
>>>   };
>>>
>>> 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.
>>
>> I wanted to kick this thread again now in the new year and see if there
>> is still some interest in pursuing this?
>>
>> There is still very much a need from a Tegra perspective. I have put all
>> those who responded on TO.
>>
>> I know that a lot of time has passed since we discuss this and so if you
>> are scratching your head wondering what I am harping on about,
>> essentially with this RFC I was looking for a way to support devices
>> that require multiple power domains where the domains do not have a
>> parent-child relationship and so not are nested in anyway.
>>
>> If you need me to elaborate on the need for this, I am happy to do this.
>> My take away from when we discussed this last year, was that there was a
>> need for this.
> 
> It definitely makes sense to me, as the "power-domains" DT binding is not
> limited to plain "power areas", but may refer to clock domains, too
> (cfr. the Linux "PM Domain" notion).
> 
> For my (Renesas) use case, we have devices that are part of both a power
> area and a clock domain. Currently this is handled by the power area driver
> calling into the clock driver.
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

-- 
nvpublic

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

[Jon Hunter]

Hi Rafael, Kevin, Ulf,

Looks like there is still some interest/needs in/for this. Any thoughts
on how we can move this forward?

Cheers
Jon

On 28/02/17 15:29, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter  wrote:
>> On 20/09/16 11:28, Jon Hunter wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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@7009 {
>>>   compatible = "nvidia,tegra210-xusb";
>>>   ...
>>>   power-domains = <_xusbhost>, <_xusbss>;
>>>   };
>>>
>>> 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.
>>
>> I wanted to kick this thread again now in the new year and see if there
>> is still some interest in pursuing this?
>>
>> There is still very much a need from a Tegra perspective. I have put all
>> those who responded on TO.
>>
>> I know that a lot of time has passed since we discuss this and so if you
>> are scratching your head wondering what I am harping on about,
>> essentially with this RFC I was looking for a way to support devices
>> that require multiple power domains where the domains do not have a
>> parent-child relationship and so not are nested in anyway.
>>
>> If you need me to elaborate on the need for this, I am happy to do this.
>> My take away from when we discussed this last year, was that there was a
>> need for this.
> 
> It definitely makes sense to me, as the "power-domains" DT binding is not
> limited to plain "power areas", but may refer to clock domains, too
> (cfr. the Linux "PM Domain" notion).
> 
> For my (Renesas) use case, we have devices that are part of both a power
> area and a clock domain. Currently this is handled by the power area driver
> calling into the clock driver.
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

-- 
nvpublic

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

[Rajendra Nayak]

On 02/28/2017 08:48 PM, Jon Hunter wrote:
> Hi all,
> 
> On 20/09/16 11:28, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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@7009 {
>>  compatible = "nvidia,tegra210-xusb";
>>  ...
>>  power-domains = <_xusbhost>, <_xusbss>;
>>  };
>>
>> 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.
> 
> I wanted to kick this thread again now in the new year and see if there
> is still some interest in pursuing this?

Thanks Jon for reviving this thread. I ran into the issue of having to
support multiple powerdomains for a single device again while working with
Viresh's 'domain performance state' patches [1], to add support for corners
on qualcomm platforms.
We do have devices which have logic and memory powered via separate rails,
and the drivers would want to set 'performance states' on both, which an
external core then translates into actual uV and programs the PMIC.

[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1340018.html

> 
> There is still very much a need from a Tegra perspective. I have put all
> those who responded on TO.
> 
> I know that a lot of time has passed since we discuss this and so if you
> are scratching your head wondering what I am harping on about,
> essentially with this RFC I was looking for a way to support devices
> that require multiple power domains where the domains do not have a
> parent-child relationship and so not are nested in anyway.
> 
> If you need me to elaborate on the need for this, I am happy to do this.
> My take away from when we discussed this last year, was that there was a
> need for this.
> 
> Cheers
> Jon
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Rajendra Nayak]

On 02/28/2017 08:48 PM, Jon Hunter wrote:
> Hi all,
> 
> On 20/09/16 11:28, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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@7009 {
>>  compatible = "nvidia,tegra210-xusb";
>>  ...
>>  power-domains = <_xusbhost>, <_xusbss>;
>>  };
>>
>> 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.
> 
> I wanted to kick this thread again now in the new year and see if there
> is still some interest in pursuing this?

Thanks Jon for reviving this thread. I ran into the issue of having to
support multiple powerdomains for a single device again while working with
Viresh's 'domain performance state' patches [1], to add support for corners
on qualcomm platforms.
We do have devices which have logic and memory powered via separate rails,
and the drivers would want to set 'performance states' on both, which an
external core then translates into actual uV and programs the PMIC.

[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1340018.html

> 
> There is still very much a need from a Tegra perspective. I have put all
> those who responded on TO.
> 
> I know that a lot of time has passed since we discuss this and so if you
> are scratching your head wondering what I am harping on about,
> essentially with this RFC I was looking for a way to support devices
> that require multiple power domains where the domains do not have a
> parent-child relationship and so not are nested in anyway.
> 
> If you need me to elaborate on the need for this, I am happy to do this.
> My take away from when we discussed this last year, was that there was a
> need for this.
> 
> Cheers
> Jon
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Geert Uytterhoeven]

Hi Jon,

On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter  wrote:
> On 20/09/16 11:28, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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@7009 {
>>   compatible = "nvidia,tegra210-xusb";
>>   ...
>>   power-domains = <_xusbhost>, <_xusbss>;
>>   };
>>
>> 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.
>
> I wanted to kick this thread again now in the new year and see if there
> is still some interest in pursuing this?
>
> There is still very much a need from a Tegra perspective. I have put all
> those who responded on TO.
>
> I know that a lot of time has passed since we discuss this and so if you
> are scratching your head wondering what I am harping on about,
> essentially with this RFC I was looking for a way to support devices
> that require multiple power domains where the domains do not have a
> parent-child relationship and so not are nested in anyway.
>
> If you need me to elaborate on the need for this, I am happy to do this.
> My take away from when we discussed this last year, was that there was a
> need for this.

It definitely makes sense to me, as the "power-domains" DT binding is not
limited to plain "power areas", but may refer to clock domains, too
(cfr. the Linux "PM Domain" notion).

For my (Renesas) use case, we have devices that are part of both a power
area and a clock domain. Currently this is handled by the power area driver
calling into the clock driver.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Geert Uytterhoeven]

Hi Jon,

On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter  wrote:
> On 20/09/16 11:28, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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@7009 {
>>   compatible = "nvidia,tegra210-xusb";
>>   ...
>>   power-domains = <_xusbhost>, <_xusbss>;
>>   };
>>
>> 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.
>
> I wanted to kick this thread again now in the new year and see if there
> is still some interest in pursuing this?
>
> There is still very much a need from a Tegra perspective. I have put all
> those who responded on TO.
>
> I know that a lot of time has passed since we discuss this and so if you
> are scratching your head wondering what I am harping on about,
> essentially with this RFC I was looking for a way to support devices
> that require multiple power domains where the domains do not have a
> parent-child relationship and so not are nested in anyway.
>
> If you need me to elaborate on the need for this, I am happy to do this.
> My take away from when we discussed this last year, was that there was a
> need for this.

It definitely makes sense to me, as the "power-domains" DT binding is not
limited to plain "power areas", but may refer to clock domains, too
(cfr. the Linux "PM Domain" notion).

For my (Renesas) use case, we have devices that are part of both a power
area and a clock domain. Currently this is handled by the power area driver
calling into the clock driver.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Jon Hunter]

Hi all,

On 20/09/16 11:28, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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@7009 {
>   compatible = "nvidia,tegra210-xusb";
>   ...
>   power-domains = <_xusbhost>, <_xusbss>;
>   };
> 
> 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.

I wanted to kick this thread again now in the new year and see if there
is still some interest in pursuing this?

There is still very much a need from a Tegra perspective. I have put all
those who responded on TO.

I know that a lot of time has passed since we discuss this and so if you
are scratching your head wondering what I am harping on about,
essentially with this RFC I was looking for a way to support devices
that require multiple power domains where the domains do not have a
parent-child relationship and so not are nested in anyway.

If you need me to elaborate on the need for this, I am happy to do this.
My take away from when we discussed this last year, was that there was a
need for this.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

Hi all,

On 20/09/16 11:28, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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@7009 {
>   compatible = "nvidia,tegra210-xusb";
>   ...
>   power-domains = <_xusbhost>, <_xusbss>;
>   };
> 
> 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.

I wanted to kick this thread again now in the new year and see if there
is still some interest in pursuing this?

There is still very much a need from a Tegra perspective. I have put all
those who responded on TO.

I know that a lot of time has passed since we discuss this and so if you
are scratching your head wondering what I am harping on about,
essentially with this RFC I was looking for a way to support devices
that require multiple power domains where the domains do not have a
parent-child relationship and so not are nested in anyway.

If you need me to elaborate on the need for this, I am happy to do this.
My take away from when we discussed this last year, was that there was a
need for this.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

On 29/11/16 11:33, Marek Szyprowski wrote:
> Hi Stephen,
> 
> Thanks for pointing to my patches, but I would like to clarify a few
> things.
> 
> On 2016-11-24 03:30, Stephen Boyd wrote:
>> On 11/22, Jon Hunter wrote:
>>> On 22/11/16 18:26, Kevin Hilman wrote:
 Jon Hunter  writes:
> 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.
>>> I agree.
>>>
>> Marek is attempting to do this for the samsung clock
>> controller[1] (patch #5 is informative).
> 
> You probably meant patch #3 / #4, which is a patch for Exynos 4412
> ( https://marc.info/?l=linux-arm-kernel=147731142926053=2 ).

Sorry for the delay, I have been meaning to get back to this thread. Yes
patch #3 is definitely interesting and highlights power-domain
complexities with various SoCs ...

https://marc.info/?l=linux-clk=147731116925951=2


> Patch #5 is for Exynos 5433, which already has separate nodes for
> each clock sub-controller, so there is no problem to add generic
> power domains there (see multiple CMU nodes):
> 
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261
> 
> 
>>  From what I can tell
>> they have one DT node for their clock controller because it's one
>> register address space to control clocks. But, certain clocks
>> exposed by that driver only work when certain power domains are
>> enabled. For example, they have a clock controller that exposes
>> clock signals for multimedia hardware blocks like video
>> accelerators, gpus, and cameras. The clocks seem to have been
>> placed inside different power domains for the multimedia hardware
>> they're associated with, so there may be 10 or so power domains
>> that need to be enabled at different times for different clocks
>> to work. If the GPU power domain isn't enabled when the GPU
>> clocks are touched by the driver, things break, etc.
>>
>> In the proposed patchset, we have the top-level clock controller
>> node with subnodes for each power domain that needs to be
>> associated with clocks inside these different multimedia blocks.
> 
> This is valid only for the Exynos4412 case (and not-yet-posted
> Exynos5422), which has a single clock controller node and patch #4
> added a sub-node for ISP clocks part (the only one which in fact
> is in the other power domain).
> 
>> So we end up with one parent device and attached driver for the
>> clock driver, and then that driver populates child nodes as
>> devices and matches up clocks with child nodes while registering
>> clks with clk_register(). Because we pass a dev pointer to
>> clk_register, we associate different devices with different
>> clocks all from the same top-level clock controller device
>> driver. Then clk framework calls runtime_pm APIs with devices
>> used during clk registration.
> 
> Right, this is how I did it for Exynos4412 case.
> 
>> Some of those devices don't have
>> any driver bound to them, which feels odd.
> 
> Well, I don't get this. In the proposed patches each sub-node has
> a separate driver, none is left without a driver.

So it seems in this solution you are creating a pseudo device in order
to control the pm-domain.

>> This seems like a case where we really want a better way to
>> explicitly control power domains without making up subnodes and
>> registering struct devices just to work around the one device to
>> one genpd construct we have today. Maybe power domains just don't
>> map to genpd though and that's the disconnect.
> 
> Having an API for full control over multiple power domain assigned to
> a single device node might indeed solve somehow this problem, but as
> long as runtime pm is tied to struct device, this will again end in
> creating virtual sub-devices per each power domain to fit runtime pm
> principles. However we might be able to avoid creating sub-nodes in
> the device tree.

Right, but what if the device is not bound to the pm-domain? What if due
to pm-domain complexities we need to have finer granularity over the
control of pm-domains?

It seems to me that because we don't 

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

[Jon Hunter]

On 29/11/16 11:33, Marek Szyprowski wrote:
> Hi Stephen,
> 
> Thanks for pointing to my patches, but I would like to clarify a few
> things.
> 
> On 2016-11-24 03:30, Stephen Boyd wrote:
>> On 11/22, Jon Hunter wrote:
>>> On 22/11/16 18:26, Kevin Hilman wrote:
 Jon Hunter  writes:
> 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.
>>> I agree.
>>>
>> Marek is attempting to do this for the samsung clock
>> controller[1] (patch #5 is informative).
> 
> You probably meant patch #3 / #4, which is a patch for Exynos 4412
> ( https://marc.info/?l=linux-arm-kernel=147731142926053=2 ).

Sorry for the delay, I have been meaning to get back to this thread. Yes
patch #3 is definitely interesting and highlights power-domain
complexities with various SoCs ...

https://marc.info/?l=linux-clk=147731116925951=2


> Patch #5 is for Exynos 5433, which already has separate nodes for
> each clock sub-controller, so there is no problem to add generic
> power domains there (see multiple CMU nodes):
> 
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261
> 
> 
>>  From what I can tell
>> they have one DT node for their clock controller because it's one
>> register address space to control clocks. But, certain clocks
>> exposed by that driver only work when certain power domains are
>> enabled. For example, they have a clock controller that exposes
>> clock signals for multimedia hardware blocks like video
>> accelerators, gpus, and cameras. The clocks seem to have been
>> placed inside different power domains for the multimedia hardware
>> they're associated with, so there may be 10 or so power domains
>> that need to be enabled at different times for different clocks
>> to work. If the GPU power domain isn't enabled when the GPU
>> clocks are touched by the driver, things break, etc.
>>
>> In the proposed patchset, we have the top-level clock controller
>> node with subnodes for each power domain that needs to be
>> associated with clocks inside these different multimedia blocks.
> 
> This is valid only for the Exynos4412 case (and not-yet-posted
> Exynos5422), which has a single clock controller node and patch #4
> added a sub-node for ISP clocks part (the only one which in fact
> is in the other power domain).
> 
>> So we end up with one parent device and attached driver for the
>> clock driver, and then that driver populates child nodes as
>> devices and matches up clocks with child nodes while registering
>> clks with clk_register(). Because we pass a dev pointer to
>> clk_register, we associate different devices with different
>> clocks all from the same top-level clock controller device
>> driver. Then clk framework calls runtime_pm APIs with devices
>> used during clk registration.
> 
> Right, this is how I did it for Exynos4412 case.
> 
>> Some of those devices don't have
>> any driver bound to them, which feels odd.
> 
> Well, I don't get this. In the proposed patches each sub-node has
> a separate driver, none is left without a driver.

So it seems in this solution you are creating a pseudo device in order
to control the pm-domain.

>> This seems like a case where we really want a better way to
>> explicitly control power domains without making up subnodes and
>> registering struct devices just to work around the one device to
>> one genpd construct we have today. Maybe power domains just don't
>> map to genpd though and that's the disconnect.
> 
> Having an API for full control over multiple power domain assigned to
> a single device node might indeed solve somehow this problem, but as
> long as runtime pm is tied to struct device, this will again end in
> creating virtual sub-devices per each power domain to fit runtime pm
> principles. However we might be able to avoid creating sub-nodes in
> the device tree.

Right, but what if the device is not bound to the pm-domain? What if due
to pm-domain complexities we need to have finer granularity over the
control of pm-domains?

It seems to me that because we don't always have foresight into 

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

[Marek Szyprowski]

Hi Stephen,

Thanks for pointing to my patches, but I would like to clarify a few things.

On 2016-11-24 03:30, Stephen Boyd wrote:

On 11/22, Jon Hunter wrote:

On 22/11/16 18:26, Kevin Hilman wrote:

Jon Hunter  writes:

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.

I agree.


Marek is attempting to do this for the samsung clock
controller[1] (patch #5 is informative).


You probably meant patch #3 / #4, which is a patch for Exynos 4412
( https://marc.info/?l=linux-arm-kernel=147731142926053=2 ).

Patch #5 is for Exynos 5433, which already has separate nodes for
each clock sub-controller, so there is no problem to add generic
power domains there (see multiple CMU nodes):

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261


 From what I can tell
they have one DT node for their clock controller because it's one
register address space to control clocks. But, certain clocks
exposed by that driver only work when certain power domains are
enabled. For example, they have a clock controller that exposes
clock signals for multimedia hardware blocks like video
accelerators, gpus, and cameras. The clocks seem to have been
placed inside different power domains for the multimedia hardware
they're associated with, so there may be 10 or so power domains
that need to be enabled at different times for different clocks
to work. If the GPU power domain isn't enabled when the GPU
clocks are touched by the driver, things break, etc.

In the proposed patchset, we have the top-level clock controller
node with subnodes for each power domain that needs to be
associated with clocks inside these different multimedia blocks.


This is valid only for the Exynos4412 case (and not-yet-posted
Exynos5422), which has a single clock controller node and patch #4
added a sub-node for ISP clocks part (the only one which in fact
is in the other power domain).


So we end up with one parent device and attached driver for the
clock driver, and then that driver populates child nodes as
devices and matches up clocks with child nodes while registering
clks with clk_register(). Because we pass a dev pointer to
clk_register, we associate different devices with different
clocks all from the same top-level clock controller device
driver. Then clk framework calls runtime_pm APIs with devices
used during clk registration.


Right, this is how I did it for Exynos4412 case.


Some of those devices don't have
any driver bound to them, which feels odd.


Well, I don't get this. In the proposed patches each sub-node has
a separate driver, none is left without a driver.


This seems like a case where we really want a better way to
explicitly control power domains without making up subnodes and
registering struct devices just to work around the one device to
one genpd construct we have today. Maybe power domains just don't
map to genpd though and that's the disconnect.


Having an API for full control over multiple power domain assigned to
a single device node might indeed solve somehow this problem, but as
long as runtime pm is tied to struct device, this will again end in
creating virtual sub-devices per each power domain to fit runtime pm
principles. However we might be able to avoid creating sub-nodes in
the device tree.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

[Marek Szyprowski]

Hi Stephen,

Thanks for pointing to my patches, but I would like to clarify a few things.

On 2016-11-24 03:30, Stephen Boyd wrote:

On 11/22, Jon Hunter wrote:

On 22/11/16 18:26, Kevin Hilman wrote:

Jon Hunter  writes:

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.

I agree.


Marek is attempting to do this for the samsung clock
controller[1] (patch #5 is informative).


You probably meant patch #3 / #4, which is a patch for Exynos 4412
( https://marc.info/?l=linux-arm-kernel=147731142926053=2 ).

Patch #5 is for Exynos 5433, which already has separate nodes for
each clock sub-controller, so there is no problem to add generic
power domains there (see multiple CMU nodes):

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261


 From what I can tell
they have one DT node for their clock controller because it's one
register address space to control clocks. But, certain clocks
exposed by that driver only work when certain power domains are
enabled. For example, they have a clock controller that exposes
clock signals for multimedia hardware blocks like video
accelerators, gpus, and cameras. The clocks seem to have been
placed inside different power domains for the multimedia hardware
they're associated with, so there may be 10 or so power domains
that need to be enabled at different times for different clocks
to work. If the GPU power domain isn't enabled when the GPU
clocks are touched by the driver, things break, etc.

In the proposed patchset, we have the top-level clock controller
node with subnodes for each power domain that needs to be
associated with clocks inside these different multimedia blocks.


This is valid only for the Exynos4412 case (and not-yet-posted
Exynos5422), which has a single clock controller node and patch #4
added a sub-node for ISP clocks part (the only one which in fact
is in the other power domain).


So we end up with one parent device and attached driver for the
clock driver, and then that driver populates child nodes as
devices and matches up clocks with child nodes while registering
clks with clk_register(). Because we pass a dev pointer to
clk_register, we associate different devices with different
clocks all from the same top-level clock controller device
driver. Then clk framework calls runtime_pm APIs with devices
used during clk registration.


Right, this is how I did it for Exynos4412 case.


Some of those devices don't have
any driver bound to them, which feels odd.


Well, I don't get this. In the proposed patches each sub-node has
a separate driver, none is left without a driver.


This seems like a case where we really want a better way to
explicitly control power domains without making up subnodes and
registering struct devices just to work around the one device to
one genpd construct we have today. Maybe power domains just don't
map to genpd though and that's the disconnect.


Having an API for full control over multiple power domain assigned to
a single device node might indeed solve somehow this problem, but as
long as runtime pm is tied to struct device, this will again end in
creating virtual sub-devices per each power domain to fit runtime pm
principles. However we might be able to avoid creating sub-nodes in
the device tree.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

[Stephen Boyd]

On 11/22, Jon Hunter wrote:
> 
> On 22/11/16 18:26, Kevin Hilman wrote:
> > Jon Hunter  writes:
> > 
> >> 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.
> 
> I agree.
> 

Marek is attempting to do this for the samsung clock
controller[1] (patch #5 is informative). From what I can tell
they have one DT node for their clock controller because it's one
register address space to control clocks. But, certain clocks
exposed by that driver only work when certain power domains are
enabled. For example, they have a clock controller that exposes
clock signals for multimedia hardware blocks like video
accelerators, gpus, and cameras. The clocks seem to have been
placed inside different power domains for the multimedia hardware
they're associated with, so there may be 10 or so power domains
that need to be enabled at different times for different clocks
to work. If the GPU power domain isn't enabled when the GPU
clocks are touched by the driver, things break, etc.

In the proposed patchset, we have the top-level clock controller
node with subnodes for each power domain that needs to be
associated with clocks inside these different multimedia blocks.
So we end up with one parent device and attached driver for the
clock driver, and then that driver populates child nodes as
devices and matches up clocks with child nodes while registering
clks with clk_register(). Because we pass a dev pointer to
clk_register, we associate different devices with different
clocks all from the same top-level clock controller device
driver. Then clk framework calls runtime_pm APIs with devices
used during clk registration. Some of those devices don't have
any driver bound to them, which feels odd.

This seems like a case where we really want a better way to
explicitly control power domains without making up subnodes and
registering struct devices just to work around the one device to
one genpd construct we have today. Maybe power domains just don't
map to genpd though and that's the disconnect.

[1] 
http://lkml.kernel.org/r/1477311130-6534-1-git-send-email-m.szyprow...@samsung.com
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Stephen Boyd]

On 11/22, Jon Hunter wrote:
> 
> On 22/11/16 18:26, Kevin Hilman wrote:
> > Jon Hunter  writes:
> > 
> >> 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.
> 
> I agree.
> 

Marek is attempting to do this for the samsung clock
controller[1] (patch #5 is informative). From what I can tell
they have one DT node for their clock controller because it's one
register address space to control clocks. But, certain clocks
exposed by that driver only work when certain power domains are
enabled. For example, they have a clock controller that exposes
clock signals for multimedia hardware blocks like video
accelerators, gpus, and cameras. The clocks seem to have been
placed inside different power domains for the multimedia hardware
they're associated with, so there may be 10 or so power domains
that need to be enabled at different times for different clocks
to work. If the GPU power domain isn't enabled when the GPU
clocks are touched by the driver, things break, etc.

In the proposed patchset, we have the top-level clock controller
node with subnodes for each power domain that needs to be
associated with clocks inside these different multimedia blocks.
So we end up with one parent device and attached driver for the
clock driver, and then that driver populates child nodes as
devices and matches up clocks with child nodes while registering
clks with clk_register(). Because we pass a dev pointer to
clk_register, we associate different devices with different
clocks all from the same top-level clock controller device
driver. Then clk framework calls runtime_pm APIs with devices
used during clk registration. Some of those devices don't have
any driver bound to them, which feels odd.

This seems like a case where we really want a better way to
explicitly control power domains without making up subnodes and
registering struct devices just to work around the one device to
one genpd construct we have today. Maybe power domains just don't
map to genpd though and that's the disconnect.

[1] 
http://lkml.kernel.org/r/1477311130-6534-1-git-send-email-m.szyprow...@samsung.com
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[Rafael J. Wysocki]

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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_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 

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

[Rafael J. Wysocki]

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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_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
> 

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

[Jon Hunter]

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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_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 

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

[Jon Hunter]

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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_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!

Cheers
Jon

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

[Rajendra Nayak]

On 11/22/2016 06:35 PM, Ulf Hansson wrote:
> On 17 November 2016 at 16:39, Stanimir Varbanov
>  wrote:
>> Hi,
>>
>> On 11/17/2016 04:31 AM, Rajendra Nayak wrote:
>>>
>>>
>>> On 11/16/2016 06:41 PM, Ulf Hansson wrote:
 On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
> Hi Jon,
>
> On 10/31/2016 04:14 PM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/10/16 09:43, Rajendra Nayak wrote:
>>>
>>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
 Hi Rajendra,

 On 06/10/16 07:04, Rajendra Nayak wrote:
>
> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and 
>> device
>> controllers) 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.
>
> Hey Jon, so does this RFC provide a way to just specify multiple 
> Powerdomains
> for a device (which then will *all* be powered on/off together) or 
> does
> it also provide for more granular control of these powerdomains?

 Only to specify multiple power-domains for a device and not the later.

> The above statement seems to suggest you would need more granular 
> control
> of these powerdomains (like keeping XUSBA off in case superspeed it 
> not
> needed) but I can't seem to figure out how you achieve it with this 
> series.

 It is an interesting point but today we have always kept the superspeed
 partition on if the device is configured for superspeed regardless of
 what is actually connected. I will check to see if the h/w would allow
 us to turn it off if a non-superspeed device is in use but I did not
 think so.

 Do you have any interesting use-cases that would make use of this or
 require other such enhancements?
>>>
>>> We do have atleast a few devices which need to control multiple power 
>>> domains,
>>> I will need to look more to see if any of them can be controlled 
>>> individually.
>>> The downstream code we have models these (powerdomains) as regulators 
>>> and
>>> the drivers hence have individual control on each (specifying multiple 
>>> -supply's
>>> in DT)
>>
>> Were you able to check to see if you need to have individual control for 
>> the power-domains?
>
> I had a look at the Video decode block (for msm8996), which seems to be 
> powered using 3 different
> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD 
> powers the ARM core
> which runs the firmware, while the venus_core0 and venus_core1 power the 
> encode/decode logic,
> so for things like firmware image loading you ideally need only venus PD 
> to be ON, but during
> an encode/decode operation you would need all 3 to be ON.

 Isn't there a scenario when encoding *or* decoding happens, not always 
 both?

 If so, doesn't that mean you may have venus + venus_core0 powered and
 in some other case venus + venus_core1 powered?

> The downstream driver turns *all* of them together, and does not control 
> them individually.
> For upstream, the way we have it working (the driver is not merged) is by 
> having venus be the parent
> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
> venus_core1 mentioned as
> the powerdomain for the video decode block in DT.
>
> So in summary, there is still no need to control them individually, but 
> given there is no way to
> specify more than one powerdomain for a given device, we are ending up 
> hooking up some
> parent/child relations in the powerdomain code.
>

 I think a better solution would be to model the video decode block as
 three struct devices.

 1) The main ARM device, attached to the venus PM domain.
 2) The encoder device, having the main device assigned as its parent
 and being attached to the venus_core0 PM domain.
 3) The decoder device, having the main device assigned as its parent
 and being attached to the 

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

[Rajendra Nayak]

On 11/22/2016 06:35 PM, Ulf Hansson wrote:
> On 17 November 2016 at 16:39, Stanimir Varbanov
>  wrote:
>> Hi,
>>
>> On 11/17/2016 04:31 AM, Rajendra Nayak wrote:
>>>
>>>
>>> On 11/16/2016 06:41 PM, Ulf Hansson wrote:
 On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
> Hi Jon,
>
> On 10/31/2016 04:14 PM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/10/16 09:43, Rajendra Nayak wrote:
>>>
>>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
 Hi Rajendra,

 On 06/10/16 07:04, Rajendra Nayak wrote:
>
> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and 
>> device
>> controllers) 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.
>
> Hey Jon, so does this RFC provide a way to just specify multiple 
> Powerdomains
> for a device (which then will *all* be powered on/off together) or 
> does
> it also provide for more granular control of these powerdomains?

 Only to specify multiple power-domains for a device and not the later.

> The above statement seems to suggest you would need more granular 
> control
> of these powerdomains (like keeping XUSBA off in case superspeed it 
> not
> needed) but I can't seem to figure out how you achieve it with this 
> series.

 It is an interesting point but today we have always kept the superspeed
 partition on if the device is configured for superspeed regardless of
 what is actually connected. I will check to see if the h/w would allow
 us to turn it off if a non-superspeed device is in use but I did not
 think so.

 Do you have any interesting use-cases that would make use of this or
 require other such enhancements?
>>>
>>> We do have atleast a few devices which need to control multiple power 
>>> domains,
>>> I will need to look more to see if any of them can be controlled 
>>> individually.
>>> The downstream code we have models these (powerdomains) as regulators 
>>> and
>>> the drivers hence have individual control on each (specifying multiple 
>>> -supply's
>>> in DT)
>>
>> Were you able to check to see if you need to have individual control for 
>> the power-domains?
>
> I had a look at the Video decode block (for msm8996), which seems to be 
> powered using 3 different
> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD 
> powers the ARM core
> which runs the firmware, while the venus_core0 and venus_core1 power the 
> encode/decode logic,
> so for things like firmware image loading you ideally need only venus PD 
> to be ON, but during
> an encode/decode operation you would need all 3 to be ON.

 Isn't there a scenario when encoding *or* decoding happens, not always 
 both?

 If so, doesn't that mean you may have venus + venus_core0 powered and
 in some other case venus + venus_core1 powered?

> The downstream driver turns *all* of them together, and does not control 
> them individually.
> For upstream, the way we have it working (the driver is not merged) is by 
> having venus be the parent
> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
> venus_core1 mentioned as
> the powerdomain for the video decode block in DT.
>
> So in summary, there is still no need to control them individually, but 
> given there is no way to
> specify more than one powerdomain for a given device, we are ending up 
> hooking up some
> parent/child relations in the powerdomain code.
>

 I think a better solution would be to model the video decode block as
 three struct devices.

 1) The main ARM device, attached to the venus PM domain.
 2) The encoder device, having the main device assigned as its parent
 and being attached to the venus_core0 PM domain.
 3) The decoder device, having the main device assigned as its parent
 and being attached to the venus_core1 PM domain.

 Then there is no need 

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

[Rafael J. Wysocki]

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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_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.

Thanks,
Rafael

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

[Rafael J. Wysocki]

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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_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.

Thanks,
Rafael

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

[Jon Hunter]

On 22/11/16 18:26, 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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_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.
> 
>> 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?

Difficult to say without all the details, for example do we need to
worry about the order in which they are power-up/down?

>> 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 

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

[Jon Hunter]

On 22/11/16 18:26, 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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_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.
> 
>> 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?

Difficult to say without all the details, for example do we need to
worry about the order in which they are power-up/down?

>> 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, 

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

[Kevin Hilman]

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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_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.

> 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 

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

[Kevin Hilman]

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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_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.

> 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 

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

[Jon Hunter]

On 22/11/16 13:31, Ulf Hansson wrote:
> On 22 November 2016 at 12:12, Jon Hunter  wrote:
>> On 16/11/16 12:53, Rafael J. Wysocki wrote:

...

>>> 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.
> 
> Hmm, going back to the original post for this thread.
> 
> This more or less sounds very similar as the case for when Rajendra
> described the problem for the video decode block in msm8996, except
> that in this case you already have couple of different struct devices
> available that for you could deploy runtime PM.

In this case there is only one device, so ...

> Then, wouldn't it be possible to assign a parent/child relationship
> for these devices, each device has its own corresponding PM domain -
> instead of having to dynamically nest PM domains.

... no that will not work in this case unless we create some sort of
dummy parent device but I was hoping to avoid that.

> Runtime PM will help to make sure parent devices are always active
> when child devices also are active.
> 
>>
>> 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.
> 
> Again, if it's possible to model the topology by using parent/child
> devices, and deploy runtime PM for them, then we shouldn't need more
> than one PM domain per device. I am not sure that works here though,
> but just and idea.

It is really not too different from how we nest power-domains today. In
fact I can manually nest them and add them to the device in the driver
with the existing genpd APIs. However, I don't have a meaningful way to
describe the power-domains that are used by the device in DT because
there is more than one.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

On 22/11/16 13:31, Ulf Hansson wrote:
> On 22 November 2016 at 12:12, Jon Hunter  wrote:
>> On 16/11/16 12:53, Rafael J. Wysocki wrote:

...

>>> 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.
> 
> Hmm, going back to the original post for this thread.
> 
> This more or less sounds very similar as the case for when Rajendra
> described the problem for the video decode block in msm8996, except
> that in this case you already have couple of different struct devices
> available that for you could deploy runtime PM.

In this case there is only one device, so ...

> Then, wouldn't it be possible to assign a parent/child relationship
> for these devices, each device has its own corresponding PM domain -
> instead of having to dynamically nest PM domains.

... no that will not work in this case unless we create some sort of
dummy parent device but I was hoping to avoid that.

> Runtime PM will help to make sure parent devices are always active
> when child devices also are active.
> 
>>
>> 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.
> 
> Again, if it's possible to model the topology by using parent/child
> devices, and deploy runtime PM for them, then we shouldn't need more
> than one PM domain per device. I am not sure that works here though,
> but just and idea.

It is really not too different from how we nest power-domains today. In
fact I can manually nest them and add them to the device in the driver
with the existing genpd APIs. However, I don't have a meaningful way to
describe the power-domains that are used by the device in DT because
there is more than one.

Cheers
Jon

-- 
nvpublic

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

[Ulf Hansson]

On 22 November 2016 at 12:12, Jon Hunter  wrote:
>
> 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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_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.

Hmm, going back to the original post for this thread.

This more or less sounds very similar as the case for when Rajendra
described the problem for the video decode block in msm8996, except
that in this case you already have couple of different struct devices
available that for you could deploy runtime PM.

Then, wouldn't it be possible to assign a parent/child relationship
for these devices, each device 

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

[Ulf Hansson]

On 22 November 2016 at 12:12, Jon Hunter  wrote:
>
> 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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_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.

Hmm, going back to the original post for this thread.

This more or less sounds very similar as the case for when Rajendra
described the problem for the video decode block in msm8996, except
that in this case you already have couple of different struct devices
available that for you could deploy runtime PM.

Then, wouldn't it be possible to assign a parent/child relationship
for these devices, each device has its own corresponding PM domain -

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

[Ulf Hansson]

On 17 November 2016 at 16:39, Stanimir Varbanov
 wrote:
> Hi,
>
> On 11/17/2016 04:31 AM, Rajendra Nayak wrote:
>>
>>
>> On 11/16/2016 06:41 PM, Ulf Hansson wrote:
>>> On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
 Hi Jon,

 On 10/31/2016 04:14 PM, Jon Hunter wrote:
> Hi Rajendra,
>
> On 06/10/16 09:43, Rajendra Nayak wrote:
>>
>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
>>> Hi Rajendra,
>>>
>>> On 06/10/16 07:04, Rajendra Nayak wrote:

 On 09/20/2016 03:58 PM, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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.

 Hey Jon, so does this RFC provide a way to just specify multiple 
 Powerdomains
 for a device (which then will *all* be powered on/off together) or does
 it also provide for more granular control of these powerdomains?
>>>
>>> Only to specify multiple power-domains for a device and not the later.
>>>
 The above statement seems to suggest you would need more granular 
 control
 of these powerdomains (like keeping XUSBA off in case superspeed it not
 needed) but I can't seem to figure out how you achieve it with this 
 series.
>>>
>>> It is an interesting point but today we have always kept the superspeed
>>> partition on if the device is configured for superspeed regardless of
>>> what is actually connected. I will check to see if the h/w would allow
>>> us to turn it off if a non-superspeed device is in use but I did not
>>> think so.
>>>
>>> Do you have any interesting use-cases that would make use of this or
>>> require other such enhancements?
>>
>> We do have atleast a few devices which need to control multiple power 
>> domains,
>> I will need to look more to see if any of them can be controlled 
>> individually.
>> The downstream code we have models these (powerdomains) as regulators and
>> the drivers hence have individual control on each (specifying multiple 
>> -supply's
>> in DT)
>
> Were you able to check to see if you need to have individual control for 
> the power-domains?

 I had a look at the Video decode block (for msm8996), which seems to be 
 powered using 3 different
 powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD 
 powers the ARM core
 which runs the firmware, while the venus_core0 and venus_core1 power the 
 encode/decode logic,
 so for things like firmware image loading you ideally need only venus PD 
 to be ON, but during
 an encode/decode operation you would need all 3 to be ON.
>>>
>>> Isn't there a scenario when encoding *or* decoding happens, not always both?
>>>
>>> If so, doesn't that mean you may have venus + venus_core0 powered and
>>> in some other case venus + venus_core1 powered?
>>>
 The downstream driver turns *all* of them together, and does not control 
 them individually.
 For upstream, the way we have it working (the driver is not merged) is by 
 having venus be the parent
 of venus_core0 and venus_core0 as the parent of venus_core1, and having 
 venus_core1 mentioned as
 the powerdomain for the video decode block in DT.

 So in summary, there is still no need to control them individually, but 
 given there is no way to
 specify more than one powerdomain for a given device, we are ending up 
 hooking up some
 parent/child relations in the powerdomain code.

>>>
>>> I think a better solution would be to model the video decode block as
>>> three struct devices.
>>>
>>> 1) The main ARM device, attached to the venus PM domain.
>>> 2) The encoder device, having the main device assigned as its parent
>>> and being attached to the venus_core0 PM domain.
>>> 3) The decoder device, having the main device assigned as its parent
>>> and being attached to the venus_core1 PM domain.
>>>
>>> Then there is no need to specific a  PM domain hierarchy (which seems
>>> to be the issue here), but instead only the parent/child relationships
>>> between the struct devices.

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

[Ulf Hansson]

On 17 November 2016 at 16:39, Stanimir Varbanov
 wrote:
> Hi,
>
> On 11/17/2016 04:31 AM, Rajendra Nayak wrote:
>>
>>
>> On 11/16/2016 06:41 PM, Ulf Hansson wrote:
>>> On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
 Hi Jon,

 On 10/31/2016 04:14 PM, Jon Hunter wrote:
> Hi Rajendra,
>
> On 06/10/16 09:43, Rajendra Nayak wrote:
>>
>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
>>> Hi Rajendra,
>>>
>>> On 06/10/16 07:04, Rajendra Nayak wrote:

 On 09/20/2016 03:58 PM, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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.

 Hey Jon, so does this RFC provide a way to just specify multiple 
 Powerdomains
 for a device (which then will *all* be powered on/off together) or does
 it also provide for more granular control of these powerdomains?
>>>
>>> Only to specify multiple power-domains for a device and not the later.
>>>
 The above statement seems to suggest you would need more granular 
 control
 of these powerdomains (like keeping XUSBA off in case superspeed it not
 needed) but I can't seem to figure out how you achieve it with this 
 series.
>>>
>>> It is an interesting point but today we have always kept the superspeed
>>> partition on if the device is configured for superspeed regardless of
>>> what is actually connected. I will check to see if the h/w would allow
>>> us to turn it off if a non-superspeed device is in use but I did not
>>> think so.
>>>
>>> Do you have any interesting use-cases that would make use of this or
>>> require other such enhancements?
>>
>> We do have atleast a few devices which need to control multiple power 
>> domains,
>> I will need to look more to see if any of them can be controlled 
>> individually.
>> The downstream code we have models these (powerdomains) as regulators and
>> the drivers hence have individual control on each (specifying multiple 
>> -supply's
>> in DT)
>
> Were you able to check to see if you need to have individual control for 
> the power-domains?

 I had a look at the Video decode block (for msm8996), which seems to be 
 powered using 3 different
 powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD 
 powers the ARM core
 which runs the firmware, while the venus_core0 and venus_core1 power the 
 encode/decode logic,
 so for things like firmware image loading you ideally need only venus PD 
 to be ON, but during
 an encode/decode operation you would need all 3 to be ON.
>>>
>>> Isn't there a scenario when encoding *or* decoding happens, not always both?
>>>
>>> If so, doesn't that mean you may have venus + venus_core0 powered and
>>> in some other case venus + venus_core1 powered?
>>>
 The downstream driver turns *all* of them together, and does not control 
 them individually.
 For upstream, the way we have it working (the driver is not merged) is by 
 having venus be the parent
 of venus_core0 and venus_core0 as the parent of venus_core1, and having 
 venus_core1 mentioned as
 the powerdomain for the video decode block in DT.

 So in summary, there is still no need to control them individually, but 
 given there is no way to
 specify more than one powerdomain for a given device, we are ending up 
 hooking up some
 parent/child relations in the powerdomain code.

>>>
>>> I think a better solution would be to model the video decode block as
>>> three struct devices.
>>>
>>> 1) The main ARM device, attached to the venus PM domain.
>>> 2) The encoder device, having the main device assigned as its parent
>>> and being attached to the venus_core0 PM domain.
>>> 3) The decoder device, having the main device assigned as its parent
>>> and being attached to the venus_core1 PM domain.
>>>
>>> Then there is no need to specific a  PM domain hierarchy (which seems
>>> to be the issue here), but instead only the parent/child relationships
>>> between the struct devices.
>>>
>>> Moreover, as you deploy runtime PM for these 

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

[Jon Hunter]

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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_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

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

[Jon Hunter]

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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_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

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

[Stanimir Varbanov]

Hi,

On 11/17/2016 04:31 AM, Rajendra Nayak wrote:
> 
> 
> On 11/16/2016 06:41 PM, Ulf Hansson wrote:
>> On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
>>> Hi Jon,
>>>
>>> On 10/31/2016 04:14 PM, Jon Hunter wrote:
 Hi Rajendra,

 On 06/10/16 09:43, Rajendra Nayak wrote:
>
> On 10/06/2016 01:55 PM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/10/16 07:04, Rajendra Nayak wrote:
>>>
>>> On 09/20/2016 03:58 PM, Jon Hunter wrote:
 The Tegra124/210 XUSB subsystem (that consists of both host and device
 controllers) 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.
>>>
>>> Hey Jon, so does this RFC provide a way to just specify multiple 
>>> Powerdomains
>>> for a device (which then will *all* be powered on/off together) or does
>>> it also provide for more granular control of these powerdomains?
>>
>> Only to specify multiple power-domains for a device and not the later.
>>
>>> The above statement seems to suggest you would need more granular 
>>> control
>>> of these powerdomains (like keeping XUSBA off in case superspeed it not
>>> needed) but I can't seem to figure out how you achieve it with this 
>>> series.
>>
>> It is an interesting point but today we have always kept the superspeed
>> partition on if the device is configured for superspeed regardless of
>> what is actually connected. I will check to see if the h/w would allow
>> us to turn it off if a non-superspeed device is in use but I did not
>> think so.
>>
>> Do you have any interesting use-cases that would make use of this or
>> require other such enhancements?
>
> We do have atleast a few devices which need to control multiple power 
> domains,
> I will need to look more to see if any of them can be controlled 
> individually.
> The downstream code we have models these (powerdomains) as regulators and
> the drivers hence have individual control on each (specifying multiple 
> -supply's
> in DT)

 Were you able to check to see if you need to have individual control for 
 the power-domains?
>>>
>>> I had a look at the Video decode block (for msm8996), which seems to be 
>>> powered using 3 different
>>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD 
>>> powers the ARM core
>>> which runs the firmware, while the venus_core0 and venus_core1 power the 
>>> encode/decode logic,
>>> so for things like firmware image loading you ideally need only venus PD to 
>>> be ON, but during
>>> an encode/decode operation you would need all 3 to be ON.
>>
>> Isn't there a scenario when encoding *or* decoding happens, not always both?
>>
>> If so, doesn't that mean you may have venus + venus_core0 powered and
>> in some other case venus + venus_core1 powered?
>>
>>> The downstream driver turns *all* of them together, and does not control 
>>> them individually.
>>> For upstream, the way we have it working (the driver is not merged) is by 
>>> having venus be the parent
>>> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
>>> venus_core1 mentioned as
>>> the powerdomain for the video decode block in DT.
>>>
>>> So in summary, there is still no need to control them individually, but 
>>> given there is no way to
>>> specify more than one powerdomain for a given device, we are ending up 
>>> hooking up some
>>> parent/child relations in the powerdomain code.
>>>
>>
>> I think a better solution would be to model the video decode block as
>> three struct devices.
>>
>> 1) The main ARM device, attached to the venus PM domain.
>> 2) The encoder device, having the main device assigned as its parent
>> and being attached to the venus_core0 PM domain.
>> 3) The decoder device, having the main device assigned as its parent
>> and being attached to the venus_core1 PM domain.
>>
>> Then there is no need to specific a  PM domain hierarchy (which seems
>> to be the issue here), but instead only the parent/child relationships
>> between the struct devices.
>>
>> Moreover, as you deploy runtime PM for these devices, you can more
>> easily distinguish which device you need to operate on
>> (pm_runtime_get|put*()) depending on what particular operations you
>> want 

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

[Stanimir Varbanov]

Hi,

On 11/17/2016 04:31 AM, Rajendra Nayak wrote:
> 
> 
> On 11/16/2016 06:41 PM, Ulf Hansson wrote:
>> On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
>>> Hi Jon,
>>>
>>> On 10/31/2016 04:14 PM, Jon Hunter wrote:
 Hi Rajendra,

 On 06/10/16 09:43, Rajendra Nayak wrote:
>
> On 10/06/2016 01:55 PM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/10/16 07:04, Rajendra Nayak wrote:
>>>
>>> On 09/20/2016 03:58 PM, Jon Hunter wrote:
 The Tegra124/210 XUSB subsystem (that consists of both host and device
 controllers) 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.
>>>
>>> Hey Jon, so does this RFC provide a way to just specify multiple 
>>> Powerdomains
>>> for a device (which then will *all* be powered on/off together) or does
>>> it also provide for more granular control of these powerdomains?
>>
>> Only to specify multiple power-domains for a device and not the later.
>>
>>> The above statement seems to suggest you would need more granular 
>>> control
>>> of these powerdomains (like keeping XUSBA off in case superspeed it not
>>> needed) but I can't seem to figure out how you achieve it with this 
>>> series.
>>
>> It is an interesting point but today we have always kept the superspeed
>> partition on if the device is configured for superspeed regardless of
>> what is actually connected. I will check to see if the h/w would allow
>> us to turn it off if a non-superspeed device is in use but I did not
>> think so.
>>
>> Do you have any interesting use-cases that would make use of this or
>> require other such enhancements?
>
> We do have atleast a few devices which need to control multiple power 
> domains,
> I will need to look more to see if any of them can be controlled 
> individually.
> The downstream code we have models these (powerdomains) as regulators and
> the drivers hence have individual control on each (specifying multiple 
> -supply's
> in DT)

 Were you able to check to see if you need to have individual control for 
 the power-domains?
>>>
>>> I had a look at the Video decode block (for msm8996), which seems to be 
>>> powered using 3 different
>>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD 
>>> powers the ARM core
>>> which runs the firmware, while the venus_core0 and venus_core1 power the 
>>> encode/decode logic,
>>> so for things like firmware image loading you ideally need only venus PD to 
>>> be ON, but during
>>> an encode/decode operation you would need all 3 to be ON.
>>
>> Isn't there a scenario when encoding *or* decoding happens, not always both?
>>
>> If so, doesn't that mean you may have venus + venus_core0 powered and
>> in some other case venus + venus_core1 powered?
>>
>>> The downstream driver turns *all* of them together, and does not control 
>>> them individually.
>>> For upstream, the way we have it working (the driver is not merged) is by 
>>> having venus be the parent
>>> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
>>> venus_core1 mentioned as
>>> the powerdomain for the video decode block in DT.
>>>
>>> So in summary, there is still no need to control them individually, but 
>>> given there is no way to
>>> specify more than one powerdomain for a given device, we are ending up 
>>> hooking up some
>>> parent/child relations in the powerdomain code.
>>>
>>
>> I think a better solution would be to model the video decode block as
>> three struct devices.
>>
>> 1) The main ARM device, attached to the venus PM domain.
>> 2) The encoder device, having the main device assigned as its parent
>> and being attached to the venus_core0 PM domain.
>> 3) The decoder device, having the main device assigned as its parent
>> and being attached to the venus_core1 PM domain.
>>
>> Then there is no need to specific a  PM domain hierarchy (which seems
>> to be the issue here), but instead only the parent/child relationships
>> between the struct devices.
>>
>> Moreover, as you deploy runtime PM for these devices, you can more
>> easily distinguish which device you need to operate on
>> (pm_runtime_get|put*()) depending on what particular operations you
>> want to do (encode, decode 

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

[Rajendra Nayak]

On 11/16/2016 06:41 PM, Ulf Hansson wrote:
> On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
>> Hi Jon,
>>
>> On 10/31/2016 04:14 PM, Jon Hunter wrote:
>>> Hi Rajendra,
>>>
>>> On 06/10/16 09:43, Rajendra Nayak wrote:

 On 10/06/2016 01:55 PM, Jon Hunter wrote:
> Hi Rajendra,
>
> On 06/10/16 07:04, Rajendra Nayak wrote:
>>
>> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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.
>>
>> Hey Jon, so does this RFC provide a way to just specify multiple 
>> Powerdomains
>> for a device (which then will *all* be powered on/off together) or does
>> it also provide for more granular control of these powerdomains?
>
> Only to specify multiple power-domains for a device and not the later.
>
>> The above statement seems to suggest you would need more granular control
>> of these powerdomains (like keeping XUSBA off in case superspeed it not
>> needed) but I can't seem to figure out how you achieve it with this 
>> series.
>
> It is an interesting point but today we have always kept the superspeed
> partition on if the device is configured for superspeed regardless of
> what is actually connected. I will check to see if the h/w would allow
> us to turn it off if a non-superspeed device is in use but I did not
> think so.
>
> Do you have any interesting use-cases that would make use of this or
> require other such enhancements?

 We do have atleast a few devices which need to control multiple power 
 domains,
 I will need to look more to see if any of them can be controlled 
 individually.
 The downstream code we have models these (powerdomains) as regulators and
 the drivers hence have individual control on each (specifying multiple 
 -supply's
 in DT)
>>>
>>> Were you able to check to see if you need to have individual control for 
>>> the power-domains?
>>
>> I had a look at the Video decode block (for msm8996), which seems to be 
>> powered using 3 different
>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers 
>> the ARM core
>> which runs the firmware, while the venus_core0 and venus_core1 power the 
>> encode/decode logic,
>> so for things like firmware image loading you ideally need only venus PD to 
>> be ON, but during
>> an encode/decode operation you would need all 3 to be ON.
> 
> Isn't there a scenario when encoding *or* decoding happens, not always both?
> 
> If so, doesn't that mean you may have venus + venus_core0 powered and
> in some other case venus + venus_core1 powered?
> 
>> The downstream driver turns *all* of them together, and does not control 
>> them individually.
>> For upstream, the way we have it working (the driver is not merged) is by 
>> having venus be the parent
>> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
>> venus_core1 mentioned as
>> the powerdomain for the video decode block in DT.
>>
>> So in summary, there is still no need to control them individually, but 
>> given there is no way to
>> specify more than one powerdomain for a given device, we are ending up 
>> hooking up some
>> parent/child relations in the powerdomain code.
>>
> 
> I think a better solution would be to model the video decode block as
> three struct devices.
> 
> 1) The main ARM device, attached to the venus PM domain.
> 2) The encoder device, having the main device assigned as its parent
> and being attached to the venus_core0 PM domain.
> 3) The decoder device, having the main device assigned as its parent
> and being attached to the venus_core1 PM domain.
> 
> Then there is no need to specific a  PM domain hierarchy (which seems
> to be the issue here), but instead only the parent/child relationships
> between the struct devices.
> 
> Moreover, as you deploy runtime PM for these devices, you can more
> easily distinguish which device you need to operate on
> (pm_runtime_get|put*()) depending on what particular operations you
> want to do (encode, decode etc).

Stan, is this something you think is possible to do, given the way the
vidc driver is designed? This is mainly for 8996 which has 3 different

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

[Rajendra Nayak]

On 11/16/2016 06:41 PM, Ulf Hansson wrote:
> On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
>> Hi Jon,
>>
>> On 10/31/2016 04:14 PM, Jon Hunter wrote:
>>> Hi Rajendra,
>>>
>>> On 06/10/16 09:43, Rajendra Nayak wrote:

 On 10/06/2016 01:55 PM, Jon Hunter wrote:
> Hi Rajendra,
>
> On 06/10/16 07:04, Rajendra Nayak wrote:
>>
>> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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.
>>
>> Hey Jon, so does this RFC provide a way to just specify multiple 
>> Powerdomains
>> for a device (which then will *all* be powered on/off together) or does
>> it also provide for more granular control of these powerdomains?
>
> Only to specify multiple power-domains for a device and not the later.
>
>> The above statement seems to suggest you would need more granular control
>> of these powerdomains (like keeping XUSBA off in case superspeed it not
>> needed) but I can't seem to figure out how you achieve it with this 
>> series.
>
> It is an interesting point but today we have always kept the superspeed
> partition on if the device is configured for superspeed regardless of
> what is actually connected. I will check to see if the h/w would allow
> us to turn it off if a non-superspeed device is in use but I did not
> think so.
>
> Do you have any interesting use-cases that would make use of this or
> require other such enhancements?

 We do have atleast a few devices which need to control multiple power 
 domains,
 I will need to look more to see if any of them can be controlled 
 individually.
 The downstream code we have models these (powerdomains) as regulators and
 the drivers hence have individual control on each (specifying multiple 
 -supply's
 in DT)
>>>
>>> Were you able to check to see if you need to have individual control for 
>>> the power-domains?
>>
>> I had a look at the Video decode block (for msm8996), which seems to be 
>> powered using 3 different
>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers 
>> the ARM core
>> which runs the firmware, while the venus_core0 and venus_core1 power the 
>> encode/decode logic,
>> so for things like firmware image loading you ideally need only venus PD to 
>> be ON, but during
>> an encode/decode operation you would need all 3 to be ON.
> 
> Isn't there a scenario when encoding *or* decoding happens, not always both?
> 
> If so, doesn't that mean you may have venus + venus_core0 powered and
> in some other case venus + venus_core1 powered?
> 
>> The downstream driver turns *all* of them together, and does not control 
>> them individually.
>> For upstream, the way we have it working (the driver is not merged) is by 
>> having venus be the parent
>> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
>> venus_core1 mentioned as
>> the powerdomain for the video decode block in DT.
>>
>> So in summary, there is still no need to control them individually, but 
>> given there is no way to
>> specify more than one powerdomain for a given device, we are ending up 
>> hooking up some
>> parent/child relations in the powerdomain code.
>>
> 
> I think a better solution would be to model the video decode block as
> three struct devices.
> 
> 1) The main ARM device, attached to the venus PM domain.
> 2) The encoder device, having the main device assigned as its parent
> and being attached to the venus_core0 PM domain.
> 3) The decoder device, having the main device assigned as its parent
> and being attached to the venus_core1 PM domain.
> 
> Then there is no need to specific a  PM domain hierarchy (which seems
> to be the issue here), but instead only the parent/child relationships
> between the struct devices.
> 
> Moreover, as you deploy runtime PM for these devices, you can more
> easily distinguish which device you need to operate on
> (pm_runtime_get|put*()) depending on what particular operations you
> want to do (encode, decode etc).

Stan, is this something you think is possible to do, given the way the
vidc driver is designed? This is mainly for 8996 which has 3 different
powerdomains associated with the 

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

[Ulf Hansson]

On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
> Hi Jon,
>
> On 10/31/2016 04:14 PM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/10/16 09:43, Rajendra Nayak wrote:
>>>
>>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
 Hi Rajendra,

 On 06/10/16 07:04, Rajendra Nayak wrote:
>
> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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.
>
> Hey Jon, so does this RFC provide a way to just specify multiple 
> Powerdomains
> for a device (which then will *all* be powered on/off together) or does
> it also provide for more granular control of these powerdomains?

 Only to specify multiple power-domains for a device and not the later.

> The above statement seems to suggest you would need more granular control
> of these powerdomains (like keeping XUSBA off in case superspeed it not
> needed) but I can't seem to figure out how you achieve it with this 
> series.

 It is an interesting point but today we have always kept the superspeed
 partition on if the device is configured for superspeed regardless of
 what is actually connected. I will check to see if the h/w would allow
 us to turn it off if a non-superspeed device is in use but I did not
 think so.

 Do you have any interesting use-cases that would make use of this or
 require other such enhancements?
>>>
>>> We do have atleast a few devices which need to control multiple power 
>>> domains,
>>> I will need to look more to see if any of them can be controlled 
>>> individually.
>>> The downstream code we have models these (powerdomains) as regulators and
>>> the drivers hence have individual control on each (specifying multiple 
>>> -supply's
>>> in DT)
>>
>> Were you able to check to see if you need to have individual control for the 
>> power-domains?
>
> I had a look at the Video decode block (for msm8996), which seems to be 
> powered using 3 different
> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers 
> the ARM core
> which runs the firmware, while the venus_core0 and venus_core1 power the 
> encode/decode logic,
> so for things like firmware image loading you ideally need only venus PD to 
> be ON, but during
> an encode/decode operation you would need all 3 to be ON.

Isn't there a scenario when encoding *or* decoding happens, not always both?

If so, doesn't that mean you may have venus + venus_core0 powered and
in some other case venus + venus_core1 powered?

> The downstream driver turns *all* of them together, and does not control them 
> individually.
> For upstream, the way we have it working (the driver is not merged) is by 
> having venus be the parent
> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
> venus_core1 mentioned as
> the powerdomain for the video decode block in DT.
>
> So in summary, there is still no need to control them individually, but given 
> there is no way to
> specify more than one powerdomain for a given device, we are ending up 
> hooking up some
> parent/child relations in the powerdomain code.
>

I think a better solution would be to model the video decode block as
three struct devices.

1) The main ARM device, attached to the venus PM domain.
2) The encoder device, having the main device assigned as its parent
and being attached to the venus_core0 PM domain.
3) The decoder device, having the main device assigned as its parent
and being attached to the venus_core1 PM domain.

Then there is no need to specific a  PM domain hierarchy (which seems
to be the issue here), but instead only the parent/child relationships
between the struct devices.

Moreover, as you deploy runtime PM for these devices, you can more
easily distinguish which device you need to operate on
(pm_runtime_get|put*()) depending on what particular operations you
want to do (encode, decode etc).

Would that work?

Kind regards
Uffe

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

[Ulf Hansson]

On 2 November 2016 at 09:56, Rajendra Nayak  wrote:
> Hi Jon,
>
> On 10/31/2016 04:14 PM, Jon Hunter wrote:
>> Hi Rajendra,
>>
>> On 06/10/16 09:43, Rajendra Nayak wrote:
>>>
>>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
 Hi Rajendra,

 On 06/10/16 07:04, Rajendra Nayak wrote:
>
> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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.
>
> Hey Jon, so does this RFC provide a way to just specify multiple 
> Powerdomains
> for a device (which then will *all* be powered on/off together) or does
> it also provide for more granular control of these powerdomains?

 Only to specify multiple power-domains for a device and not the later.

> The above statement seems to suggest you would need more granular control
> of these powerdomains (like keeping XUSBA off in case superspeed it not
> needed) but I can't seem to figure out how you achieve it with this 
> series.

 It is an interesting point but today we have always kept the superspeed
 partition on if the device is configured for superspeed regardless of
 what is actually connected. I will check to see if the h/w would allow
 us to turn it off if a non-superspeed device is in use but I did not
 think so.

 Do you have any interesting use-cases that would make use of this or
 require other such enhancements?
>>>
>>> We do have atleast a few devices which need to control multiple power 
>>> domains,
>>> I will need to look more to see if any of them can be controlled 
>>> individually.
>>> The downstream code we have models these (powerdomains) as regulators and
>>> the drivers hence have individual control on each (specifying multiple 
>>> -supply's
>>> in DT)
>>
>> Were you able to check to see if you need to have individual control for the 
>> power-domains?
>
> I had a look at the Video decode block (for msm8996), which seems to be 
> powered using 3 different
> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers 
> the ARM core
> which runs the firmware, while the venus_core0 and venus_core1 power the 
> encode/decode logic,
> so for things like firmware image loading you ideally need only venus PD to 
> be ON, but during
> an encode/decode operation you would need all 3 to be ON.

Isn't there a scenario when encoding *or* decoding happens, not always both?

If so, doesn't that mean you may have venus + venus_core0 powered and
in some other case venus + venus_core1 powered?

> The downstream driver turns *all* of them together, and does not control them 
> individually.
> For upstream, the way we have it working (the driver is not merged) is by 
> having venus be the parent
> of venus_core0 and venus_core0 as the parent of venus_core1, and having 
> venus_core1 mentioned as
> the powerdomain for the video decode block in DT.
>
> So in summary, there is still no need to control them individually, but given 
> there is no way to
> specify more than one powerdomain for a given device, we are ending up 
> hooking up some
> parent/child relations in the powerdomain code.
>

I think a better solution would be to model the video decode block as
three struct devices.

1) The main ARM device, attached to the venus PM domain.
2) The encoder device, having the main device assigned as its parent
and being attached to the venus_core0 PM domain.
3) The decoder device, having the main device assigned as its parent
and being attached to the venus_core1 PM domain.

Then there is no need to specific a  PM domain hierarchy (which seems
to be the issue here), but instead only the parent/child relationships
between the struct devices.

Moreover, as you deploy runtime PM for these devices, you can more
easily distinguish which device you need to operate on
(pm_runtime_get|put*()) depending on what particular operations you
want to do (encode, decode etc).

Would that work?

Kind regards
Uffe

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

[Rafael J. Wysocki]

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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_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

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

[Rafael J. Wysocki]

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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_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

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

[Jon Hunter]

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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_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.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_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.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_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.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_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.

Cheers
Jon

-- 
nvpublic

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

[Rajendra Nayak]

Hi Jon,

On 10/31/2016 04:14 PM, Jon Hunter wrote:
> Hi Rajendra,
> 
> On 06/10/16 09:43, Rajendra Nayak wrote:
>>
>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
>>> Hi Rajendra,
>>>
>>> On 06/10/16 07:04, Rajendra Nayak wrote:

 On 09/20/2016 03:58 PM, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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.

 Hey Jon, so does this RFC provide a way to just specify multiple 
 Powerdomains
 for a device (which then will *all* be powered on/off together) or does
 it also provide for more granular control of these powerdomains?
>>>
>>> Only to specify multiple power-domains for a device and not the later.
>>>
 The above statement seems to suggest you would need more granular control
 of these powerdomains (like keeping XUSBA off in case superspeed it not
 needed) but I can't seem to figure out how you achieve it with this series.
>>>
>>> It is an interesting point but today we have always kept the superspeed
>>> partition on if the device is configured for superspeed regardless of
>>> what is actually connected. I will check to see if the h/w would allow
>>> us to turn it off if a non-superspeed device is in use but I did not
>>> think so.
>>>
>>> Do you have any interesting use-cases that would make use of this or
>>> require other such enhancements?
>>
>> We do have atleast a few devices which need to control multiple power 
>> domains,
>> I will need to look more to see if any of them can be controlled 
>> individually.
>> The downstream code we have models these (powerdomains) as regulators and
>> the drivers hence have individual control on each (specifying multiple 
>> -supply's
>> in DT)
> 
> Were you able to check to see if you need to have individual control for the 
> power-domains?

I had a look at the Video decode block (for msm8996), which seems to be powered 
using 3 different
powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers 
the ARM core
which runs the firmware, while the venus_core0 and venus_core1 power the 
encode/decode logic,
so for things like firmware image loading you ideally need only venus PD to be 
ON, but during
an encode/decode operation you would need all 3 to be ON.
The downstream driver turns *all* of them together, and does not control them 
individually.
For upstream, the way we have it working (the driver is not merged) is by 
having venus be the parent
of venus_core0 and venus_core0 as the parent of venus_core1, and having 
venus_core1 mentioned as
the powerdomain for the video decode block in DT.

So in summary, there is still no need to control them individually, but given 
there is no way to
specify more than one powerdomain for a given device, we are ending up hooking 
up some 
parent/child relations in the powerdomain code.

regards,
Rajendra

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Rajendra Nayak]

Hi Jon,

On 10/31/2016 04:14 PM, Jon Hunter wrote:
> Hi Rajendra,
> 
> On 06/10/16 09:43, Rajendra Nayak wrote:
>>
>> On 10/06/2016 01:55 PM, Jon Hunter wrote:
>>> Hi Rajendra,
>>>
>>> On 06/10/16 07:04, Rajendra Nayak wrote:

 On 09/20/2016 03:58 PM, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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.

 Hey Jon, so does this RFC provide a way to just specify multiple 
 Powerdomains
 for a device (which then will *all* be powered on/off together) or does
 it also provide for more granular control of these powerdomains?
>>>
>>> Only to specify multiple power-domains for a device and not the later.
>>>
 The above statement seems to suggest you would need more granular control
 of these powerdomains (like keeping XUSBA off in case superspeed it not
 needed) but I can't seem to figure out how you achieve it with this series.
>>>
>>> It is an interesting point but today we have always kept the superspeed
>>> partition on if the device is configured for superspeed regardless of
>>> what is actually connected. I will check to see if the h/w would allow
>>> us to turn it off if a non-superspeed device is in use but I did not
>>> think so.
>>>
>>> Do you have any interesting use-cases that would make use of this or
>>> require other such enhancements?
>>
>> We do have atleast a few devices which need to control multiple power 
>> domains,
>> I will need to look more to see if any of them can be controlled 
>> individually.
>> The downstream code we have models these (powerdomains) as regulators and
>> the drivers hence have individual control on each (specifying multiple 
>> -supply's
>> in DT)
> 
> Were you able to check to see if you need to have individual control for the 
> power-domains?

I had a look at the Video decode block (for msm8996), which seems to be powered 
using 3 different
powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers 
the ARM core
which runs the firmware, while the venus_core0 and venus_core1 power the 
encode/decode logic,
so for things like firmware image loading you ideally need only venus PD to be 
ON, but during
an encode/decode operation you would need all 3 to be ON.
The downstream driver turns *all* of them together, and does not control them 
individually.
For upstream, the way we have it working (the driver is not merged) is by 
having venus be the parent
of venus_core0 and venus_core0 as the parent of venus_core1, and having 
venus_core1 mentioned as
the powerdomain for the video decode block in DT.

So in summary, there is still no need to control them individually, but given 
there is no way to
specify more than one powerdomain for a given device, we are ending up hooking 
up some 
parent/child relations in the powerdomain code.

regards,
Rajendra

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Jon Hunter]

Hi Rajendra,

On 06/10/16 09:43, Rajendra Nayak wrote:


On 10/06/2016 01:55 PM, Jon Hunter wrote:

Hi Rajendra,

On 06/10/16 07:04, Rajendra Nayak wrote:


On 09/20/2016 03:58 PM, Jon Hunter wrote:

The Tegra124/210 XUSB subsystem (that consists of both host and device
controllers) 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.


Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
for a device (which then will *all* be powered on/off together) or does
it also provide for more granular control of these powerdomains?


Only to specify multiple power-domains for a device and not the later.


The above statement seems to suggest you would need more granular control
of these powerdomains (like keeping XUSBA off in case superspeed it not
needed) but I can't seem to figure out how you achieve it with this series.


It is an interesting point but today we have always kept the superspeed
partition on if the device is configured for superspeed regardless of
what is actually connected. I will check to see if the h/w would allow
us to turn it off if a non-superspeed device is in use but I did not
think so.

Do you have any interesting use-cases that would make use of this or
require other such enhancements?


We do have atleast a few devices which need to control multiple power domains,
I will need to look more to see if any of them can be controlled individually.
The downstream code we have models these (powerdomains) as regulators and
the drivers hence have individual control on each (specifying multiple -supply's
in DT)


Were you able to check to see if you need to have individual control for 
the power-domains?


Cheers
Jon

--
nvpublic

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

[Jon Hunter]

Hi Rajendra,

On 06/10/16 09:43, Rajendra Nayak wrote:


On 10/06/2016 01:55 PM, Jon Hunter wrote:

Hi Rajendra,

On 06/10/16 07:04, Rajendra Nayak wrote:


On 09/20/2016 03:58 PM, Jon Hunter wrote:

The Tegra124/210 XUSB subsystem (that consists of both host and device
controllers) 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.


Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
for a device (which then will *all* be powered on/off together) or does
it also provide for more granular control of these powerdomains?


Only to specify multiple power-domains for a device and not the later.


The above statement seems to suggest you would need more granular control
of these powerdomains (like keeping XUSBA off in case superspeed it not
needed) but I can't seem to figure out how you achieve it with this series.


It is an interesting point but today we have always kept the superspeed
partition on if the device is configured for superspeed regardless of
what is actually connected. I will check to see if the h/w would allow
us to turn it off if a non-superspeed device is in use but I did not
think so.

Do you have any interesting use-cases that would make use of this or
require other such enhancements?


We do have atleast a few devices which need to control multiple power domains,
I will need to look more to see if any of them can be controlled individually.
The downstream code we have models these (powerdomains) as regulators and
the drivers hence have individual control on each (specifying multiple -supply's
in DT)


Were you able to check to see if you need to have individual control for 
the power-domains?


Cheers
Jon

--
nvpublic

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

[Jon Hunter]

On 10/10/16 15:04, Ulf Hansson wrote:
> On 10 October 2016 at 13:18, Jon Hunter  wrote:
>>
>> On 06/10/16 13:22, Ulf Hansson wrote:
>>> On 20 September 2016 at 12:28, Jon Hunter  wrote:
 The Tegra124/210 XUSB subsystem (that consists of both host and device
 controllers) 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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_xusbss>;
 };

 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.
>>>
>>> First, I don't really like extending the internal logic of genpd to
>>> deal with multiple PM domains per device. *If* this really is needed,
>>> I think we should try to extend the struct device to cover this, then
>>> make genpd to use it somehow.
>>
>> I had looked at that initially but it was looking quite complex because
>> of the various structures (dev_pm_domain in the device structure,
>> pm_domain_data in pm_subsys_data, etc). This implementation is quite
> 
> I didn't care much about the complexity, more trying to understand how
> the HW actually works. :-)

OK.

>> simple and less intrusive. However, if there is a lot of interest in
>> this and it does appear to be, I would agree that having the device
>> structure handle this would be best.
>>
>>> 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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_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.

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

On 10/10/16 15:04, Ulf Hansson wrote:
> On 10 October 2016 at 13:18, Jon Hunter  wrote:
>>
>> On 06/10/16 13:22, Ulf Hansson wrote:
>>> On 20 September 2016 at 12:28, Jon Hunter  wrote:
 The Tegra124/210 XUSB subsystem (that consists of both host and device
 controllers) 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@7009 {
 compatible = "nvidia,tegra210-xusb";
 ...
 power-domains = <_xusbhost>, <_xusbss>;
 };

 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.
>>>
>>> First, I don't really like extending the internal logic of genpd to
>>> deal with multiple PM domains per device. *If* this really is needed,
>>> I think we should try to extend the struct device to cover this, then
>>> make genpd to use it somehow.
>>
>> I had looked at that initially but it was looking quite complex because
>> of the various structures (dev_pm_domain in the device structure,
>> pm_domain_data in pm_subsys_data, etc). This implementation is quite
> 
> I didn't care much about the complexity, more trying to understand how
> the HW actually works. :-)

OK.

>> simple and less intrusive. However, if there is a lot of interest in
>> this and it does appear to be, I would agree that having the device
>> structure handle this would be best.
>>
>>> 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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_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.

Cheers
Jon

-- 
nvpublic

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

[Ulf Hansson]

On 10 October 2016 at 13:18, Jon Hunter  wrote:
>
> On 06/10/16 13:22, Ulf Hansson wrote:
>> On 20 September 2016 at 12:28, Jon Hunter  wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_xusbss>;
>>> };
>>>
>>> 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.
>>
>> First, I don't really like extending the internal logic of genpd to
>> deal with multiple PM domains per device. *If* this really is needed,
>> I think we should try to extend the struct device to cover this, then
>> make genpd to use it somehow.
>
> I had looked at that initially but it was looking quite complex because
> of the various structures (dev_pm_domain in the device structure,
> pm_domain_data in pm_subsys_data, etc). This implementation is quite

I didn't care much about the complexity, more trying to understand how
the HW actually works. :-)

> simple and less intrusive. However, if there is a lot of interest in
> this and it does appear to be, I would agree that having the device
> structure handle this would be best.
>
>> 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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_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?

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? :-)

Kind regards
Uffe

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

[Ulf Hansson]

On 10 October 2016 at 13:18, Jon Hunter  wrote:
>
> On 06/10/16 13:22, Ulf Hansson wrote:
>> On 20 September 2016 at 12:28, Jon Hunter  wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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@7009 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <_xusbhost>, <_xusbss>;
>>> };
>>>
>>> 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.
>>
>> First, I don't really like extending the internal logic of genpd to
>> deal with multiple PM domains per device. *If* this really is needed,
>> I think we should try to extend the struct device to cover this, then
>> make genpd to use it somehow.
>
> I had looked at that initially but it was looking quite complex because
> of the various structures (dev_pm_domain in the device structure,
> pm_domain_data in pm_subsys_data, etc). This implementation is quite

I didn't care much about the complexity, more trying to understand how
the HW actually works. :-)

> simple and less intrusive. However, if there is a lot of interest in
> this and it does appear to be, I would agree that having the device
> structure handle this would be best.
>
>> 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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_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?

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? :-)

Kind regards
Uffe

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

[Jon Hunter]

On 06/10/16 13:22, Ulf Hansson wrote:
> On 20 September 2016 at 12:28, Jon Hunter  wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_xusbss>;
>> };
>>
>> 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.
> 
> First, I don't really like extending the internal logic of genpd to
> deal with multiple PM domains per device. *If* this really is needed,
> I think we should try to extend the struct device to cover this, then
> make genpd to use it somehow.

I had looked at that initially but it was looking quite complex because
of the various structures (dev_pm_domain in the device structure,
pm_domain_data in pm_subsys_data, etc). This implementation is quite
simple and less intrusive. However, if there is a lot of interest in
this and it does appear to be, I would agree that having the device
structure handle this would be best.

> 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@7009 {
compatible = "nvidia,tegra210-xusb";
...
power-domains = <_xusbhost>, <_xusbss>;
};

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

On 06/10/16 13:22, Ulf Hansson wrote:
> On 20 September 2016 at 12:28, Jon Hunter  wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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@7009 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <_xusbhost>, <_xusbss>;
>> };
>>
>> 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.
> 
> First, I don't really like extending the internal logic of genpd to
> deal with multiple PM domains per device. *If* this really is needed,
> I think we should try to extend the struct device to cover this, then
> make genpd to use it somehow.

I had looked at that initially but it was looking quite complex because
of the various structures (dev_pm_domain in the device structure,
pm_domain_data in pm_subsys_data, etc). This implementation is quite
simple and less intrusive. However, if there is a lot of interest in
this and it does appear to be, I would agree that having the device
structure handle this would be best.

> 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@7009 {
compatible = "nvidia,tegra210-xusb";
...
power-domains = <_xusbhost>, <_xusbss>;
};

Cheers
Jon

-- 
nvpublic

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

[Ulf Hansson]

On 20 September 2016 at 12:28, Jon Hunter  wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_xusbss>;
> };
>
> 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.

First, I don't really like extending the internal logic of genpd to
deal with multiple PM domains per device. *If* this really is needed,
I think we should try to extend the struct device to cover this, then
make genpd to use it somehow.

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?

[...]

Kind regards
Uffe

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

[Ulf Hansson]

On 20 September 2016 at 12:28, Jon Hunter  wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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@7009 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <_xusbhost>, <_xusbss>;
> };
>
> 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.

First, I don't really like extending the internal logic of genpd to
deal with multiple PM domains per device. *If* this really is needed,
I think we should try to extend the struct device to cover this, then
make genpd to use it somehow.

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?

[...]

Kind regards
Uffe

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

[Rajendra Nayak]

On 10/06/2016 01:55 PM, Jon Hunter wrote:
> Hi Rajendra,
> 
> On 06/10/16 07:04, Rajendra Nayak wrote:
>>
>> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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.
>>
>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
>> for a device (which then will *all* be powered on/off together) or does
>> it also provide for more granular control of these powerdomains?
> 
> Only to specify multiple power-domains for a device and not the later.
> 
>> The above statement seems to suggest you would need more granular control
>> of these powerdomains (like keeping XUSBA off in case superspeed it not
>> needed) but I can't seem to figure out how you achieve it with this series.
> 
> It is an interesting point but today we have always kept the superspeed
> partition on if the device is configured for superspeed regardless of
> what is actually connected. I will check to see if the h/w would allow
> us to turn it off if a non-superspeed device is in use but I did not
> think so.
> 
> Do you have any interesting use-cases that would make use of this or
> require other such enhancements?

We do have atleast a few devices which need to control multiple power domains,
I will need to look more to see if any of them can be controlled individually.
The downstream code we have models these (powerdomains) as regulators and
the drivers hence have individual control on each (specifying multiple -supply's
in DT)
Regardless, the idea of being able to specify more than one powerdomain
associated to a device seems quite useful, though providing a way for the
driver to control them individually seems tricky.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Rajendra Nayak]

On 10/06/2016 01:55 PM, Jon Hunter wrote:
> Hi Rajendra,
> 
> On 06/10/16 07:04, Rajendra Nayak wrote:
>>
>> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) 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.
>>
>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
>> for a device (which then will *all* be powered on/off together) or does
>> it also provide for more granular control of these powerdomains?
> 
> Only to specify multiple power-domains for a device and not the later.
> 
>> The above statement seems to suggest you would need more granular control
>> of these powerdomains (like keeping XUSBA off in case superspeed it not
>> needed) but I can't seem to figure out how you achieve it with this series.
> 
> It is an interesting point but today we have always kept the superspeed
> partition on if the device is configured for superspeed regardless of
> what is actually connected. I will check to see if the h/w would allow
> us to turn it off if a non-superspeed device is in use but I did not
> think so.
> 
> Do you have any interesting use-cases that would make use of this or
> require other such enhancements?

We do have atleast a few devices which need to control multiple power domains,
I will need to look more to see if any of them can be controlled individually.
The downstream code we have models these (powerdomains) as regulators and
the drivers hence have individual control on each (specifying multiple -supply's
in DT)
Regardless, the idea of being able to specify more than one powerdomain
associated to a device seems quite useful, though providing a way for the
driver to control them individually seems tricky.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Jon Hunter]

Hi Rajendra,

On 06/10/16 07:04, Rajendra Nayak wrote:
> 
> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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.
> 
> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
> for a device (which then will *all* be powered on/off together) or does
> it also provide for more granular control of these powerdomains?

Only to specify multiple power-domains for a device and not the later.

> The above statement seems to suggest you would need more granular control
> of these powerdomains (like keeping XUSBA off in case superspeed it not
> needed) but I can't seem to figure out how you achieve it with this series.

It is an interesting point but today we have always kept the superspeed
partition on if the device is configured for superspeed regardless of
what is actually connected. I will check to see if the h/w would allow
us to turn it off if a non-superspeed device is in use but I did not
think so.

Do you have any interesting use-cases that would make use of this or
require other such enhancements?

Cheers
Jon

-- 
nvpublic

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

[Jon Hunter]

Hi Rajendra,

On 06/10/16 07:04, Rajendra Nayak wrote:
> 
> On 09/20/2016 03:58 PM, Jon Hunter wrote:
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) 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.
> 
> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
> for a device (which then will *all* be powered on/off together) or does
> it also provide for more granular control of these powerdomains?

Only to specify multiple power-domains for a device and not the later.

> The above statement seems to suggest you would need more granular control
> of these powerdomains (like keeping XUSBA off in case superspeed it not
> needed) but I can't seem to figure out how you achieve it with this series.

It is an interesting point but today we have always kept the superspeed
partition on if the device is configured for superspeed regardless of
what is actually connected. I will check to see if the h/w would allow
us to turn it off if a non-superspeed device is in use but I did not
think so.

Do you have any interesting use-cases that would make use of this or
require other such enhancements?

Cheers
Jon

-- 
nvpublic

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

[Rajendra Nayak]

On 09/20/2016 03:58 PM, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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.

Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
for a device (which then will *all* be powered on/off together) or does
it also provide for more granular control of these powerdomains?
The above statement seems to suggest you would need more granular control
of these powerdomains (like keeping XUSBA off in case superspeed it not
needed) but I can't seem to figure out how you achieve it with this series.

- Rajendra
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Rajendra Nayak]

On 09/20/2016 03:58 PM, Jon Hunter wrote:
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) 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.

Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains
for a device (which then will *all* be powered on/off together) or does
it also provide for more granular control of these powerdomains?
The above statement seems to suggest you would need more granular control
of these powerdomains (like keeping XUSBA off in case superspeed it not
needed) but I can't seem to figure out how you achieve it with this series.

- Rajendra
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[Jon Hunter]

The Tegra124/210 XUSB subsystem (that consists of both host and device
controllers) 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@7009 {
compatible = "nvidia,tegra210-xusb";
...
power-domains = <_xusbhost>, <_xusbss>;
};

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.

Jon Hunter (3):
  PM / Domains: Add helper functions for finding and attaching PM
domains
  PM / Domains: Add support for devices with multiple domains
  dt-bindings: Add support for devices with multiple PM domains

 .../devicetree/bindings/power/power_domain.txt |   5 +-
 drivers/base/power/domain.c| 205 +++--
 2 files changed, 155 insertions(+), 55 deletions(-)

-- 
2.1.4

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

[Jon Hunter]

The Tegra124/210 XUSB subsystem (that consists of both host and device
controllers) 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@7009 {
compatible = "nvidia,tegra210-xusb";
...
power-domains = <_xusbhost>, <_xusbss>;
};

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.

Jon Hunter (3):
  PM / Domains: Add helper functions for finding and attaching PM
domains
  PM / Domains: Add support for devices with multiple domains
  dt-bindings: Add support for devices with multiple PM domains

 .../devicetree/bindings/power/power_domain.txt |   5 +-
 drivers/base/power/domain.c| 205 +++--
 2 files changed, 155 insertions(+), 55 deletions(-)

-- 
2.1.4