| Message ID | 20220804103456.3176943-1-abel.vesa@linaro.org (mailing list archive) |
|---|---|
| State | Deferred |
| Headers | show |
| Series | [RFC] clk: qcom: common: Detach the power domain at the end of probe | expand |
On Thu, 4 Aug 2022 at 13:35, Abel Vesa <abel.vesa@linaro.org> wrote: > > None of the CCs actually need the PD attached to their device, > but rather some GDSCs registered by those CCs need that PD as a parent > in order to propagate power gating and the performance state. > > So lets detach the PD from the CC right at the end of probe, after > everything has been successfully set up. Would it still be possible to read the clock registers if we detach the device from the domain? I think it was the original issue behind putting the dispcc/videocc into the MMCX domain: to be able to poke into the clock registers, which are gated by the MMCX. > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
On 22-08-04 17:37:48, Dmitry Baryshkov wrote: > On Thu, 4 Aug 2022 at 13:35, Abel Vesa <abel.vesa@linaro.org> wrote: > > > > None of the CCs actually need the PD attached to their device, > > but rather some GDSCs registered by those CCs need that PD as a parent > > in order to propagate power gating and the performance state. > > > > So lets detach the PD from the CC right at the end of probe, after > > everything has been successfully set up. > > Would it still be possible to read the clock registers if we detach > the device from the domain? > I think it was the original issue behind putting the dispcc/videocc > into the MMCX domain: to be able to poke into the clock registers, > which are gated by the MMCX. +Rajendra OK, so I might be wrong here, so I'll need to double check. But, AFAICT, today, most of the CCs devicetree nodes do not have a power-domain property. So I assuming the PD is never really needed for register access by the CC itself, but its only use is to be set as parent to those GDSCs that do not have specified a different parent. Again, I need to double check. > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > -- > With best wishes > Dmitry
On Thu, Aug 04, 2022 at 05:37:48PM +0300, Dmitry Baryshkov wrote: > On Thu, 4 Aug 2022 at 13:35, Abel Vesa <abel.vesa@linaro.org> wrote: > > > > None of the CCs actually need the PD attached to their device, > > but rather some GDSCs registered by those CCs need that PD as a parent > > in order to propagate power gating and the performance state. > > > > So lets detach the PD from the CC right at the end of probe, after > > everything has been successfully set up. > > Would it still be possible to read the clock registers if we detach > the device from the domain? > I think it was the original issue behind putting the dispcc/videocc > into the MMCX domain: to be able to poke into the clock registers, > which are gated by the MMCX. > I share the understanding, that on several modern platforms e.g. dispcc was shown to depend on mmcx and the associated gcc abh clock being enabled. @Abel, could you please verify this on 8250/8350/8450? Regards, Bjorn > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > -- > With best wishes > Dmitry
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c index 75f09e6e057e..c918c91775ae 100644 --- a/drivers/clk/qcom/common.c +++ b/drivers/clk/qcom/common.c @@ -303,6 +303,8 @@ int qcom_cc_really_probe(struct platform_device *pdev, if (ret) return ret; + dev_pm_domain_detach(dev, true); + return 0; } EXPORT_SYMBOL_GPL(qcom_cc_really_probe);
None of the CCs actually need the PD attached to their device, but rather some GDSCs registered by those CCs need that PD as a parent in order to propagate power gating and the performance state. So lets detach the PD from the CC right at the end of probe, after everything has been successfully set up. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> --- drivers/clk/qcom/common.c | 2 ++ 1 file changed, 2 insertions(+)