mbox series

[0/6] clk: qcom: use power-domain for sm8250's clock controllers

Message ID 20210630133149.3204290-1-dmitry.baryshkov@linaro.org
Headers show
Series clk: qcom: use power-domain for sm8250's clock controllers | expand

Message

Dmitry Baryshkov June 30, 2021, 1:31 p.m. UTC
On SM8250 both the display and video clock controllers are powered up by
the MMCX power domain. Handle this link in GDSC code by using
pm_runtime_get/put to enable and disable the MMCX power domain.

----------------------------------------------------------------
Dmitry Baryshkov (6):
      dt-bindings: clock: qcom,dispcc-sm8x50: add mmcx power domain
      dt-bindings: clock: qcom,videocc: add mmcx power domain
      clk: qcom: gdsc: enable optional power domain support
      arm64: dts: qcom: sm8250: remove mmcx regulator
      clk: qcom: dispcc-sm8250: stop using mmcx regulator
      clk: qcom: videocc-sm8250: stop using mmcx regulator

 .../bindings/clock/qcom,dispcc-sm8x50.yaml         | 19 ++++++++
 .../devicetree/bindings/clock/qcom,videocc.yaml    | 19 ++++++++
 arch/arm64/boot/dts/qcom/sm8250.dtsi               | 13 ++---
 drivers/clk/qcom/common.c                          | 55 +++++++++++++++++++---
 drivers/clk/qcom/dispcc-sm8250.c                   |  1 -
 drivers/clk/qcom/gdsc.c                            |  6 +++
 drivers/clk/qcom/videocc-sm8250.c                  |  4 --
 7 files changed, 97 insertions(+), 20 deletions(-)

Comments

Bjorn Andersson June 30, 2021, 5:12 p.m. UTC | #1
On Wed 30 Jun 08:31 CDT 2021, Dmitry Baryshkov wrote:

> Now as the common qcom clock controller code has been taught about power
> domains, stop mentioning mmcx supply as a way to power up the clock
> controller's gdsc.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  drivers/clk/qcom/dispcc-sm8250.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/clk/qcom/dispcc-sm8250.c b/drivers/clk/qcom/dispcc-sm8250.c
> index de09cd5c209f..dfbfe64b12f6 100644
> --- a/drivers/clk/qcom/dispcc-sm8250.c
> +++ b/drivers/clk/qcom/dispcc-sm8250.c
> @@ -955,7 +955,6 @@ static struct gdsc mdss_gdsc = {
>  	},
>  	.pwrsts = PWRSTS_OFF_ON,
>  	.flags = HW_CTRL,
> -	.supply = "mmcx",
>  };
>  
>  static struct clk_regmap *disp_cc_sm8250_clocks[] = {
> -- 
> 2.30.2
>
Ulf Hansson July 1, 2021, 4:16 p.m. UTC | #2
On Wed, 30 Jun 2021 at 15:31, Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>

> On sm8250 dispcc requires MMCX power domain to be powered up before

> clock controller's registers become available. For now sm8250 was using

> external regulator driven by the power domain to describe this

> relationship. Switch into specifying power-domain and required opp-state

> directly.

>

> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> ---

>  .../bindings/clock/qcom,dispcc-sm8x50.yaml    | 19 +++++++++++++++++++

>  1 file changed, 19 insertions(+)

>

> diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> index 0cdf53f41f84..48d86fb34fa7 100644

> --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> @@ -55,6 +55,16 @@ properties:

>    reg:

>      maxItems: 1

>

> +  power-domains:

> +    description:

> +      A phandle and PM domain specifier for the MMCX power domain.

> +    maxItems: 1

> +


Should you perhaps state that this is a parent domain? Or it isn't?

Related to this and because this is a power domain provider, you
should probably reference the common power-domain bindings somewhere
here. Along the lines of this:

- $ref: power-domain.yaml#

As an example, you could have a look at
Documentation/devicetree/bindings/power/pd-samsung.yaml.

> +  required-opps:

> +    description:

> +      Performance state to use for MMCX to enable register access.

> +    maxItems: 1


According to the previous discussions, I was under the assumption that
this property belongs to a consumer node rather than in the provider
node, no?

> +

>  required:

>    - compatible

>    - reg

> @@ -64,6 +74,15 @@ required:

>    - '#reset-cells'

>    - '#power-domain-cells'

>

> +# Either both properties are present or both are absent

> +dependencies:

> +  power-domains:

> +    required:

> +      - required-opps

> +  required-opps:

> +    required:

> +      - power-domains

> +

>  additionalProperties: false

>

>  examples:

> --

> 2.30.2

>


Kind regards
Uffe
Dmitry Baryshkov July 1, 2021, 4:39 p.m. UTC | #3
On Thu, 1 Jul 2021 at 19:17, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Wed, 30 Jun 2021 at 15:31, Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On sm8250 dispcc requires MMCX power domain to be powered up before
> > clock controller's registers become available. For now sm8250 was using
> > external regulator driven by the power domain to describe this
> > relationship. Switch into specifying power-domain and required opp-state
> > directly.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> >  .../bindings/clock/qcom,dispcc-sm8x50.yaml    | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> > index 0cdf53f41f84..48d86fb34fa7 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> > @@ -55,6 +55,16 @@ properties:
> >    reg:
> >      maxItems: 1
> >
> > +  power-domains:
> > +    description:
> > +      A phandle and PM domain specifier for the MMCX power domain.
> > +    maxItems: 1
> > +
>
> Should you perhaps state that this is a parent domain? Or it isn't?
>
> Related to this and because this is a power domain provider, you
> should probably reference the common power-domain bindings somewhere
> here. Along the lines of this:
>
> - $ref: power-domain.yaml#
>
> As an example, you could have a look at
> Documentation/devicetree/bindings/power/pd-samsung.yaml.

I'll take a look.

>
> > +  required-opps:
> > +    description:
> > +      Performance state to use for MMCX to enable register access.
> > +    maxItems: 1
>
> According to the previous discussions, I was under the assumption that
> this property belongs to a consumer node rather than in the provider
> node, no?

It is both a consumer and a provider. It consumes SM8250_MMCX from
rpmhpd and provides MMSC_GDSC.

>
> > +
> >  required:
> >    - compatible
> >    - reg
> > @@ -64,6 +74,15 @@ required:
> >    - '#reset-cells'
> >    - '#power-domain-cells'
> >
> > +# Either both properties are present or both are absent
> > +dependencies:
> > +  power-domains:
> > +    required:
> > +      - required-opps
> > +  required-opps:
> > +    required:
> > +      - power-domains
> > +
> >  additionalProperties: false
> >
> >  examples:
> > --
> > 2.30.2
> >
>
> Kind regards
> Uffe
Ulf Hansson July 1, 2021, 4:58 p.m. UTC | #4
On Thu, 1 Jul 2021 at 18:39, Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Thu, 1 Jul 2021 at 19:17, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Wed, 30 Jun 2021 at 15:31, Dmitry Baryshkov
> > <dmitry.baryshkov@linaro.org> wrote:
> > >
> > > On sm8250 dispcc requires MMCX power domain to be powered up before
> > > clock controller's registers become available. For now sm8250 was using
> > > external regulator driven by the power domain to describe this
> > > relationship. Switch into specifying power-domain and required opp-state
> > > directly.
> > >
> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > ---
> > >  .../bindings/clock/qcom,dispcc-sm8x50.yaml    | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> > > index 0cdf53f41f84..48d86fb34fa7 100644
> > > --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> > > +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
> > > @@ -55,6 +55,16 @@ properties:
> > >    reg:
> > >      maxItems: 1
> > >
> > > +  power-domains:
> > > +    description:
> > > +      A phandle and PM domain specifier for the MMCX power domain.
> > > +    maxItems: 1
> > > +
> >
> > Should you perhaps state that this is a parent domain? Or it isn't?
> >
> > Related to this and because this is a power domain provider, you
> > should probably reference the common power-domain bindings somewhere
> > here. Along the lines of this:
> >
> > - $ref: power-domain.yaml#
> >
> > As an example, you could have a look at
> > Documentation/devicetree/bindings/power/pd-samsung.yaml.
>
> I'll take a look.
>
> >
> > > +  required-opps:
> > > +    description:
> > > +      Performance state to use for MMCX to enable register access.
> > > +    maxItems: 1
> >
> > According to the previous discussions, I was under the assumption that
> > this property belongs to a consumer node rather than in the provider
> > node, no?
>
> It is both a consumer and a provider. It consumes SM8250_MMCX from
> rpmhpd and provides MMSC_GDSC.

That sounds a bit weird to me.

In my view and per the common power domain bindings (as pointed to
above): If a power domain provider is a consumer of another power
domain, that per definition means that there is a parent domain
specified.

[...]

Kind regards
Uffe
Bjorn Andersson July 1, 2021, 7:26 p.m. UTC | #5
On Thu 01 Jul 11:58 CDT 2021, Ulf Hansson wrote:

> On Thu, 1 Jul 2021 at 18:39, Dmitry Baryshkov

> <dmitry.baryshkov@linaro.org> wrote:

> >

> > On Thu, 1 Jul 2021 at 19:17, Ulf Hansson <ulf.hansson@linaro.org> wrote:

> > >

> > > On Wed, 30 Jun 2021 at 15:31, Dmitry Baryshkov

> > > <dmitry.baryshkov@linaro.org> wrote:

> > > >

> > > > On sm8250 dispcc requires MMCX power domain to be powered up before

> > > > clock controller's registers become available. For now sm8250 was using

> > > > external regulator driven by the power domain to describe this

> > > > relationship. Switch into specifying power-domain and required opp-state

> > > > directly.

> > > >

> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> > > > ---

> > > >  .../bindings/clock/qcom,dispcc-sm8x50.yaml    | 19 +++++++++++++++++++

> > > >  1 file changed, 19 insertions(+)

> > > >

> > > > diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > index 0cdf53f41f84..48d86fb34fa7 100644

> > > > --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > @@ -55,6 +55,16 @@ properties:

> > > >    reg:

> > > >      maxItems: 1

> > > >

> > > > +  power-domains:

> > > > +    description:

> > > > +      A phandle and PM domain specifier for the MMCX power domain.

> > > > +    maxItems: 1

> > > > +

> > >

> > > Should you perhaps state that this is a parent domain? Or it isn't?

> > >

> > > Related to this and because this is a power domain provider, you

> > > should probably reference the common power-domain bindings somewhere

> > > here. Along the lines of this:

> > >

> > > - $ref: power-domain.yaml#

> > >

> > > As an example, you could have a look at

> > > Documentation/devicetree/bindings/power/pd-samsung.yaml.

> >

> > I'll take a look.

> >

> > >

> > > > +  required-opps:

> > > > +    description:

> > > > +      Performance state to use for MMCX to enable register access.

> > > > +    maxItems: 1

> > >

> > > According to the previous discussions, I was under the assumption that

> > > this property belongs to a consumer node rather than in the provider

> > > node, no?

> >

> > It is both a consumer and a provider. It consumes SM8250_MMCX from

> > rpmhpd and provides MMSC_GDSC.

> 

> That sounds a bit weird to me.

> 


dispcc is a hardware block powered by MMCX, so it is a consumer of it
and needs to control MMCX.

> In my view and per the common power domain bindings (as pointed to

> above): If a power domain provider is a consumer of another power

> domain, that per definition means that there is a parent domain

> specified.

> 


And in addition to needing MMCX to access the dispcc, the exposed
power-domain "MDSS_GDSC" is powered by the same MMCX and as such
MDSS_GDSC should be a subdomain of MMCX.


But what I was trying to say yesterday is that the power-domain property
should be sufficient and that we shouldn't need to drive MMCX to a
particular performance_state in order to access the registers.

Then as clients make votes on clock rates that requires higher
performance_state, they would describe this in their opp-tables etc.


But without any performance_state requests, pd->corner will in
rpmhpd_power_on() be 0 and as such powering on the power-domain won't
actually do anything. Similarly dev_pm_genpd_set_performance_state(dev,
0) on an active power-domain from rpmhpd will turn it off.


So the reason why Dmitry is adding the required-opps to the binding is
to get rpmhpd to actually tell the hardware to turn on the power domain.
And I don't think this is in accordance with the framework's
expectations.

Regards,
Bjorn
Ulf Hansson July 6, 2021, 7:23 a.m. UTC | #6
On Thu, 1 Jul 2021 at 21:26, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
>

> On Thu 01 Jul 11:58 CDT 2021, Ulf Hansson wrote:

>

> > On Thu, 1 Jul 2021 at 18:39, Dmitry Baryshkov

> > <dmitry.baryshkov@linaro.org> wrote:

> > >

> > > On Thu, 1 Jul 2021 at 19:17, Ulf Hansson <ulf.hansson@linaro.org> wrote:

> > > >

> > > > On Wed, 30 Jun 2021 at 15:31, Dmitry Baryshkov

> > > > <dmitry.baryshkov@linaro.org> wrote:

> > > > >

> > > > > On sm8250 dispcc requires MMCX power domain to be powered up before

> > > > > clock controller's registers become available. For now sm8250 was using

> > > > > external regulator driven by the power domain to describe this

> > > > > relationship. Switch into specifying power-domain and required opp-state

> > > > > directly.

> > > > >

> > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> > > > > ---

> > > > >  .../bindings/clock/qcom,dispcc-sm8x50.yaml    | 19 +++++++++++++++++++

> > > > >  1 file changed, 19 insertions(+)

> > > > >

> > > > > diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > > index 0cdf53f41f84..48d86fb34fa7 100644

> > > > > --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > > +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > > @@ -55,6 +55,16 @@ properties:

> > > > >    reg:

> > > > >      maxItems: 1

> > > > >

> > > > > +  power-domains:

> > > > > +    description:

> > > > > +      A phandle and PM domain specifier for the MMCX power domain.

> > > > > +    maxItems: 1

> > > > > +

> > > >

> > > > Should you perhaps state that this is a parent domain? Or it isn't?

> > > >

> > > > Related to this and because this is a power domain provider, you

> > > > should probably reference the common power-domain bindings somewhere

> > > > here. Along the lines of this:

> > > >

> > > > - $ref: power-domain.yaml#

> > > >

> > > > As an example, you could have a look at

> > > > Documentation/devicetree/bindings/power/pd-samsung.yaml.

> > >

> > > I'll take a look.

> > >

> > > >

> > > > > +  required-opps:

> > > > > +    description:

> > > > > +      Performance state to use for MMCX to enable register access.

> > > > > +    maxItems: 1

> > > >

> > > > According to the previous discussions, I was under the assumption that

> > > > this property belongs to a consumer node rather than in the provider

> > > > node, no?

> > >

> > > It is both a consumer and a provider. It consumes SM8250_MMCX from

> > > rpmhpd and provides MMSC_GDSC.

> >

> > That sounds a bit weird to me.

> >

>

> dispcc is a hardware block powered by MMCX, so it is a consumer of it

> and needs to control MMCX.


Right, that sounds reasonable.

>

> > In my view and per the common power domain bindings (as pointed to

> > above): If a power domain provider is a consumer of another power

> > domain, that per definition means that there is a parent domain

> > specified.

> >

>

> And in addition to needing MMCX to access the dispcc, the exposed

> power-domain "MDSS_GDSC" is powered by the same MMCX and as such

> MDSS_GDSC should be a subdomain of MMCX.


What do you mean by "exposed"? It sounds like you are saying that
"MDSS_GDSC" is an artificial power domain, no?

If that's the case, more exactly, why is it like this?

My apologies if I bother you with details, but as a maintainer of
genpd, it is very useful to me to have the complete picture.

>

>

> But what I was trying to say yesterday is that the power-domain property

> should be sufficient and that we shouldn't need to drive MMCX to a

> particular performance_state in order to access the registers.

>

> Then as clients make votes on clock rates that requires higher

> performance_state, they would describe this in their opp-tables etc.

>

>

> But without any performance_state requests, pd->corner will in

> rpmhpd_power_on() be 0 and as such powering on the power-domain won't

> actually do anything. Similarly dev_pm_genpd_set_performance_state(dev,

> 0) on an active power-domain from rpmhpd will turn it off.


Yes, I noticed the patches you posted. Thanks for helping out here!

>

>

> So the reason why Dmitry is adding the required-opps to the binding is

> to get rpmhpd to actually tell the hardware to turn on the power domain.

> And I don't think this is in accordance with the framework's

> expectations.


I agree!

>

> Regards,

> Bjorn


Kind regards
Uffe
Bjorn Andersson July 7, 2021, 5:03 a.m. UTC | #7
On Tue 06 Jul 02:23 CDT 2021, Ulf Hansson wrote:

> On Thu, 1 Jul 2021 at 21:26, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:

> >

> > On Thu 01 Jul 11:58 CDT 2021, Ulf Hansson wrote:

> >

> > > On Thu, 1 Jul 2021 at 18:39, Dmitry Baryshkov

> > > <dmitry.baryshkov@linaro.org> wrote:

> > > >

> > > > On Thu, 1 Jul 2021 at 19:17, Ulf Hansson <ulf.hansson@linaro.org> wrote:

> > > > >

> > > > > On Wed, 30 Jun 2021 at 15:31, Dmitry Baryshkov

> > > > > <dmitry.baryshkov@linaro.org> wrote:

> > > > > >

> > > > > > On sm8250 dispcc requires MMCX power domain to be powered up before

> > > > > > clock controller's registers become available. For now sm8250 was using

> > > > > > external regulator driven by the power domain to describe this

> > > > > > relationship. Switch into specifying power-domain and required opp-state

> > > > > > directly.

> > > > > >

> > > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> > > > > > ---

> > > > > >  .../bindings/clock/qcom,dispcc-sm8x50.yaml    | 19 +++++++++++++++++++

> > > > > >  1 file changed, 19 insertions(+)

> > > > > >

> > > > > > diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > > > index 0cdf53f41f84..48d86fb34fa7 100644

> > > > > > --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > > > +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml

> > > > > > @@ -55,6 +55,16 @@ properties:

> > > > > >    reg:

> > > > > >      maxItems: 1

> > > > > >

> > > > > > +  power-domains:

> > > > > > +    description:

> > > > > > +      A phandle and PM domain specifier for the MMCX power domain.

> > > > > > +    maxItems: 1

> > > > > > +

> > > > >

> > > > > Should you perhaps state that this is a parent domain? Or it isn't?

> > > > >

> > > > > Related to this and because this is a power domain provider, you

> > > > > should probably reference the common power-domain bindings somewhere

> > > > > here. Along the lines of this:

> > > > >

> > > > > - $ref: power-domain.yaml#

> > > > >

> > > > > As an example, you could have a look at

> > > > > Documentation/devicetree/bindings/power/pd-samsung.yaml.

> > > >

> > > > I'll take a look.

> > > >

> > > > >

> > > > > > +  required-opps:

> > > > > > +    description:

> > > > > > +      Performance state to use for MMCX to enable register access.

> > > > > > +    maxItems: 1

> > > > >

> > > > > According to the previous discussions, I was under the assumption that

> > > > > this property belongs to a consumer node rather than in the provider

> > > > > node, no?

> > > >

> > > > It is both a consumer and a provider. It consumes SM8250_MMCX from

> > > > rpmhpd and provides MMSC_GDSC.

> > >

> > > That sounds a bit weird to me.

> > >

> >

> > dispcc is a hardware block powered by MMCX, so it is a consumer of it

> > and needs to control MMCX.

> 

> Right, that sounds reasonable.

> 

> >

> > > In my view and per the common power domain bindings (as pointed to

> > > above): If a power domain provider is a consumer of another power

> > > domain, that per definition means that there is a parent domain

> > > specified.

> > >

> >

> > And in addition to needing MMCX to access the dispcc, the exposed

> > power-domain "MDSS_GDSC" is powered by the same MMCX and as such

> > MDSS_GDSC should be a subdomain of MMCX.

> 

> What do you mean by "exposed"? It sounds like you are saying that

> "MDSS_GDSC" is an artificial power domain, no?

> 

> If that's the case, more exactly, why is it like this?

> 

> My apologies if I bother you with details, but as a maintainer of

> genpd, it is very useful to me to have the complete picture.

> 


The display hardware blocks are powered by the MDSS_GDSC power-domain,
which is a subdomain to the MMCX power domain.

MDSS_GDSC is controlled by registers in the display clock controller
block, which is also powered by the MMCX power domain.

Lastly the MMCX power domain is controlled through the RPMh, using the
rpmhpd driver.



As such, specifying MMCX as the power-domain for the dispcc block and
making the dispcc driver use that same power-domain as parent for the
MDSS_GDSC seems to accurately depict these relationships.

Regards,
Bjorn

> >

> >

> > But what I was trying to say yesterday is that the power-domain property

> > should be sufficient and that we shouldn't need to drive MMCX to a

> > particular performance_state in order to access the registers.

> >

> > Then as clients make votes on clock rates that requires higher

> > performance_state, they would describe this in their opp-tables etc.

> >

> >

> > But without any performance_state requests, pd->corner will in

> > rpmhpd_power_on() be 0 and as such powering on the power-domain won't

> > actually do anything. Similarly dev_pm_genpd_set_performance_state(dev,

> > 0) on an active power-domain from rpmhpd will turn it off.

> 

> Yes, I noticed the patches you posted. Thanks for helping out here!

> 

> >

> >

> > So the reason why Dmitry is adding the required-opps to the binding is

> > to get rpmhpd to actually tell the hardware to turn on the power domain.

> > And I don't think this is in accordance with the framework's

> > expectations.

> 

> I agree!

> 

> >

> > Regards,

> > Bjorn

> 

> Kind regards

> Uffe