On Wed, Nov 02, 2022 at 01:28:48PM +0530, Shazad Hussain wrote:
> On 11/2/2022 12:46 PM, Johan Hovold wrote:
> > On Tue, Nov 01, 2022 at 11:23:59AM -0700, Stephen Boyd wrote:
> >> Quoting Shazad Hussain (2022-10-30 07:23:33)
> >>> Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref
> >>
> >> So we should have a Fixes tag for this commit? Or really back to the
> >> beginning of the driver?
> >>
> >>> clock for ufs_mem_phy")' we need to explicitly make cxo as parent to
> >>> gcc_ufs_ref_clkref_clk to have an independent vote from ufs_mem_phy.
> >
> > The commit message is slightly misleading as this affects the other UFS
> > PHY as well.
> >
> > If CX is indeed a parent of this clock then the issue has been there
> > since the clock driver was added. (And otherwise, the PHY binding may
> > need to be amended instead.)
> CX is not the actual parent of this clk. GCC_UFS_REF_CLKREF_CLK is an
> external clk to the device, which needs to be voted. If we use the
> GCC_UFS_REF_CLKREF_CLK as ref clk, we don't have explicit vote for CX
> from ufs_mem_phy.
>
> If no client votes for CX,(very unlikely) then it's won't be ON for
> ufs_mem_phy as well right ! So to maintain the voting to CX, we make
> this as parent to ref clk.
Right, but if the PHYs really requires CX and it is not an ancestor of
the refclk then this should be described by the binding (and not be
hidden away in the clock driver).
Johan
