clk: qcom: gcc-sc8280xp: add cxo as parent for gcc_ufs_ref_clkref_clk

Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref 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.

Signed-off-by Shazad Hussain <[email protected]>

Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref

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.

Quoting Shazad Hussain (2022-10-30 07:23:33)

Quoted 1 line

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?

Quoted 2 lines

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.

Quoted 8 lines · Stephen Boyd

Quoting Shazad Hussain (2022-10-30 07:23:33)

Quoted 1 line

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?

Quoted 2 lines

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.)

Johan

Quoted 10 lines · Johan Hovold

Quoted 8 lines · Stephen Boyd

Quoting Shazad Hussain (2022-10-30 07:23:33)

Quoted 1 line

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?

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 18 lines · Shazad Hussain

Quoted 10 lines · Johan Hovold

Quoted 8 lines · Stephen Boyd

Quoting Shazad Hussain (2022-10-30 07:23:33)

Quoted 1 line

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?

Quoted 2 lines

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.

Quoted 6 lines

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.)

Quoted 8 lines

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

Quoted 3 lines · Johan Hovold

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).

This makes sense, will be posting v2 post for the same. I assume this should use the Fixes tag then !

Quoted 8 lines · Shazad Hussain

Quoted 3 lines · Johan Hovold

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).

This makes sense, will be posting v2 post for the same. I assume this should use the Fixes tag then !

Yeah, I guess to you can add a fixes tag for the commits adding support for sc8280xp to the UFS PHY binding and driver.

But please do check with the hardware documentation first so we get this right this time.

I've already asked Bjorn to see what he can dig out as it is still not clear how the two "card" refclocks (GCC_UFS_CARD_CLKREF_CLK and GCC_UFS_1_CARD_CLKREF_CLK) are supposed to be used.

Quoted 16 lines · Johan Hovold

Quoted 8 lines · Shazad Hussain

Quoted 3 lines · Johan Hovold

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).

This makes sense, will be posting v2 post for the same. I assume this should use the Fixes tag then !

Yeah, I guess to you can add a fixes tag for the commits adding support for sc8280xp to the UFS PHY binding and driver.

But please do check with the hardware documentation first so we get this right this time.

Quoted 4 lines

I've already asked Bjorn to see what he can dig out as it is still not clear how the two "card" refclocks (GCC_UFS_CARD_CLKREF_CLK and GCC_UFS_1_CARD_CLKREF_CLK) are supposed to be used.

We've come full circle and Shazad's patch came from that discussion :)

In line with the downstream dts, we have GCC_UFS{,_1}_CARD_CLKREF_CLK providing a reference clock to the two phys. Then GCC_UFS_REF_CLKREF_CLK feeds the UFS refclock pads (both of them), which connect to the memory device(s).

In other words, GCC_UFS{,_1}_CARD_CLKREF_CLK should be "ref" in respective phy.

GCC_UFS_REF_CLKREF_CLK is the clock to the devices, but as we don't represent the memory device explicitly it seems suitable to use as "ref_clk" in the ufshc nodes - which would then match the special handling of the "link clock" in the UFS driver.

All three clocks are sourced off the CXO pad, so I would like this patch to cover at least all of these. And

Fixes d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver")

seems to be in order for such patch.

@Johan, would you mind writing a dts patch flipping the clocks around and Shazad can update this patch?

Quoted 17 lines · Bjorn Andersson

Quoted 16 lines · Johan Hovold

Quoted 8 lines · Shazad Hussain

Quoted 3 lines · Johan Hovold

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).

This makes sense, will be posting v2 post for the same. I assume this should use the Fixes tag then !

Yeah, I guess to you can add a fixes tag for the commits adding support for sc8280xp to the UFS PHY binding and driver.

But please do check with the hardware documentation first so we get this right this time.

Quoted 6 lines

Quoted 4 lines

I've already asked Bjorn to see what he can dig out as it is still not clear how the two "card" refclocks (GCC_UFS_CARD_CLKREF_CLK and GCC_UFS_1_CARD_CLKREF_CLK) are supposed to be used.

We've come full circle and Shazad's patch came from that discussion :)

Ah, good. :)

Quoted 5 lines

In line with the downstream dts, we have GCC_UFS{,_1}_CARD_CLKREF_CLK providing a reference clock to the two phys. Then GCC_UFS_REF_CLKREF_CLK feeds the UFS refclock pads (both of them), which connect to the memory device(s).

Quoted 7 lines

In other words, GCC_UFS{,_1}_CARD_CLKREF_CLK should be "ref" in respective phy.

GCC_UFS_REF_CLKREF_CLK is the clock to the devices, but as we don't represent the memory device explicitly it seems suitable to use as "ref_clk" in the ufshc nodes - which would then match the special handling of the "link clock" in the UFS driver.

Thanks for clearing that up. Using GCC_UFS_REF_CLKREF_CLK as ref_clk for the controller sounds reasonable.

I guess the only missing piece is which "card" ref clock is used by which PHY.

The ADP dts uses:

	phy			ref clock

	phy@1d87000 (UFS_PHY)	GCC_UFS_CARD_CLKREF_CLK
	phy@1da7000 (UFS_CARD)	GCC_UFS_1_CARD_CLKREF_CLK

but that is not what the firmware on ADP and CRD seem to enable.

Both the ADP and CRD fw leaves GCC_UFS_1_CARD_CLKREF_CLK enabled, while GCC_UFS_CARD_CLKREF_CLK is only enabled on ADP (which unlike the CRD also uses the UFS_CARD controller).

Does the ADP dts have these clocks switched or is the firmware confused?

(Also note that experiments suggest that neither refclock appears to has to be explicitly enabled for the controllers to function.)

Quoted 10 lines

All three clocks are sourced off the CXO pad, so I would like this patch to cover at least all of these. And

Fixes d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver")

seems to be in order for such patch.

@Johan, would you mind writing a dts patch flipping the clocks around and Shazad can update this patch?

I'll do so, but I'll wait with posting until you can confirm which clkref is which.

Johan

Quoted 23 lines · Johan Hovold

Quoted 5 lines · Bjorn Andersson

In line with the downstream dts, we have GCC_UFS{,_1}_CARD_CLKREF_CLK providing a reference clock to the two phys. Then GCC_UFS_REF_CLKREF_CLK feeds the UFS refclock pads (both of them), which connect to the memory device(s).

Quoted 7 lines

In other words, GCC_UFS{,_1}_CARD_CLKREF_CLK should be "ref" in respective phy.

GCC_UFS_REF_CLKREF_CLK is the clock to the devices, but as we don't represent the memory device explicitly it seems suitable to use as "ref_clk" in the ufshc nodes - which would then match the special handling of the "link clock" in the UFS driver.

Thanks for clearing that up. Using GCC_UFS_REF_CLKREF_CLK as ref_clk for the controller sounds reasonable.

I guess the only missing piece is which "card" ref clock is used by which PHY.

The ADP dts uses:

Quoted 5 lines

	phy			ref clock

	phy@1d87000 (UFS_PHY)	GCC_UFS_CARD_CLKREF_CLK
	phy@1da7000 (UFS_CARD)	GCC_UFS_1_CARD_CLKREF_CLK

This matches the documentation.

Quoted 5 lines

Quoted 5 lines

All three clocks are sourced off the CXO pad, so I would like this patch to cover at least all of these. And

Fixes d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver")

Quoted 8 lines

Quoted 5 lines

seems to be in order for such patch.

@Johan, would you mind writing a dts patch flipping the clocks around and Shazad can update this patch?

I'll do so, but I'll wait with posting until you can confirm which clkref is which.

Since 'commit f3aa975e230e ("arm64: dts: qcom: sc8280xp: correct ref 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.

Signed-off-by Shazad Hussain <[email protected]>

---
 drivers/clk/qcom/gcc-sc8280xp.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/clk/qcom/gcc-sc8280xp.c +2 -0

index a18ed88f3b82..72b545121c57 100644
@@ -5848,6 +5848,8 @@ static struct clk_branch gcc_ufs_ref_clkref_clk = {
 		.enable_mask = BIT(0),
 		.hw.init = &(const struct clk_init_data) {
 			.name = "gcc_ufs_ref_clkref_clk",
+			.parent_data = &gcc_parent_data_tcxo,
+			.num_parents = 1,
 			.ops = &clk_branch2_ops,
 		},
 	},

Signature · 1 line

2.38.0