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 <[email protected]>
---
drivers/clk/qcom/common.c | 2 ++
1 file changed, 2 insertions(+)
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);
--
2.34.1
On Thu, 4 Aug 2022 at 13:35, Abel Vesa <[email protected]> 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 <[email protected]>
--
With best wishes
Dmitry
On 22-08-04 17:37:48, Dmitry Baryshkov wrote:
> On Thu, 4 Aug 2022 at 13:35, Abel Vesa <[email protected]> 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 <[email protected]>
>
>
> --
> 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 <[email protected]> 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 <[email protected]>
>
>
> --
> With best wishes
> Dmitry