On Thu, 1 Jul 2021 at 13:01, Dmitry Baryshkov
[off-list ref] wrote:

On Thu, 1 Jul 2021 at 13:07, Ulf Hansson [off-list ref] wrote:

quoted

On Tue, 29 Jun 2021 at 17:09, Bjorn Andersson
[off-list ref] wrote:

quoted

On Mon 28 Jun 14:55 CDT 2021, Dmitry Baryshkov wrote:

quoted

Hi,

On 17/06/2021 12:07, Ulf Hansson wrote:

quoted

+ Rajendra

On Tue, 15 Jun 2021 at 17:55, Bjorn Andersson
[off-list ref] wrote:

[..]

quoted

quoted

quoted

But I am unable to find a way for the gdsc driver to get hold of the
struct generic_pm_domain of the resources exposed by the rpmhpd driver.

You don't need a handle to the struct generic_pm_domain, to assign a
parent/child domain. Instead you can use of_genpd_add_subdomain(),
which takes two "struct of_phandle_args*" corresponding to the
parent/child device nodes of the genpd providers and then let genpd
internally do the look up.

[..]

quoted

I think I'd need this function anyway for the gdsc code. During gdsc_init()
we check gdsc status and this requires register access (and thus powering on
the parent domain) before the gdsc is registered itself as a power domain.

But this is a register access in the dispcc block, which is the context
that our gdsc_init() operates. So describing that MMCX is the
power-domain for dispcc should ensure that the power-domain is enabled.

Right.

As a note, when we assign a child domain to a parent domain, via
of_genpd_add_subdomain() for example - and the child domain has been
powered on, this requires the parent domain to be turned on as well.

Most probably we should also teach genpd code to call pm_runtime
functions on respective devices when the genpd is powered on or off.
For now I had to do this manually.

No, that's not the way it works or should work for that matter.

It's the runtime PM status of the devices that are attached to a
genpd, that controls whether a genpd should be powered on/off.
Additionally, if there is a child domain powered on, then its parent
needs to be powered on too and so forth.

quoted

quoted

We do however need to make sure that dispcc doesn't hog its
power-domain, and that any register accesses in runtime is done with the
parenting power-domain enabled. E.g. the clock framework wraps all
operations in pm_runtime_get/put(), but I don't see anything in the
gnepd code for this.


And for gcc I'm worried that we might have some GDSCs that are parented
by CX and some by MX, but I do still think that the register accesses
are only related to one of these.

But this seems like a continuation of the special case in dispcc, so I
think we should be able to focus on getting that right before we attempt
the general case (and I don't know if we have a need for this today).

Regards,
Bjorn

Unfortunately, I didn't understand all the above things.

In any case, please tell me if there is anything else that blocks you
from moving forward with the power domain conversion? I am happy to
help.

Patch series was submitted:
https://lore.kernel.org/linux-arm-msm/20210630133149.3204290-1-dmitry.baryshkov@linaro.org/ (local)

Okay, I will have a look over there. Thanks!

Kind regards
Uffe