On Tue, 7 Sept 2021 at 17:34, Ulf Hansson [off-list ref] wrote:

On Sun, 29 Aug 2021 at 17:54, Dmitry Baryshkov
[off-list ref] wrote:

quoted

On Sun, 29 Aug 2021 at 06:51, Stephen Boyd [off-list ref] wrote:

quoted

Quoting Dmitry Baryshkov (2021-08-26 14:56:23)

quoted

On 26/08/2021 21:31, Stephen Boyd wrote:

quoted

Quoting Dmitry Baryshkov (2021-07-27 13:19:56)

quoted

On SM8250 both the display and video clock controllers are powered up by
the MMCX power domain. Handle this by linking clock controllers to the
proper power domain, and using runtime power management to enable and
disable the MMCX power domain.

Dependencies:
- https://lore.kernel.org/linux-arm-msm/20210703005416.2668319-1-bjorn.andersson@linaro.org/ (local)
   (pending)

Does this patch series need to go through the qcom tree? Presumably the
dependency is going through qcom -> arm-soc

It looks like Bjorn did not apply his patches in the for-5.15 series, so
we'd have to wait anyway. Probably I should rebase these patches instead
on Rajendra's required-opps patch (which is going in this window).

Ok. Thanks. I'll drop it from my queue for now.

Just for the reference. I've sent v7 of this patchset. After thinking
more about power domains relationship, I think we have a hole in the
abstraction here. Currently subdomains cause power domains to be
powered up, but do not dictate the performance level the parent domain
should be working in.

That's not entirely true. In genpd_add_subdomain() we verify that if
the child is powered on, the parent must already be powered on,
otherwise we treat this a bad setup and return an error code.

What seems to be missing though, is that if there is a performance
state applied for the child domain, that should be propagated to the
parent domain too. Right?

quoted

While this does not look like an issue for the
gdsc (and thus it can be easily solved by the Bjorn's patches, which
enforce rpmhpd to be powered on to 'at least lowest possible'
performance state, this might be not the case for the future links. I
think at some point the pd_add_subdomain() interface should be
extended with the ability to specify minimum required performance
state when the link becomes on.

I guess that minimum performance state could be considered as a
"required-opp" in the DT node for the power-domain provider, no?

Yes, up to some point. But this enforces a particular driver code
(that I've had to change from v6 to v7).

In v6 the gdsc's power_on code would pm_runtime_get() the provider
device, power on the domain and the pm_runtime_put() the provider
device. Thus the gdsc genpd would be powered on (keeping parent
domains in the on state), but the provider device itself would be
runtime-suspended (neat idea by Bjorn). However this relied on changes
in rpmhpd behaviour (which still did not make it to linux-next).

In v7 we have to keep the provider device in resumed state while the
gdsc genpd is powered on (to keep the required-opps vote in place).

I suppose that 'child requires minimum parent's performance state'
might become common property at some point, allowing us to drop this
pm_runtime handling.

Another option would simply be to manage this solely in the
platform/soc specific genpd provider. Would that work?

Yes, I've had this in the very old iteration of mmcx fixup patchset
(even before mmcx-regulator came into play). It ended up with quite an
ugly piece of code.

quoted

Until that time I have changed code to
enforce having clock controller in pm resume state when gdsc is
enabled, thus CC itself votes on parent's (rpmhpd) performance state.


--
With best wishes
Dmitry

Kind regards
Uffe

-- 
With best wishes
Dmitry