Re: [PATCH v3 5/5] phy: qcom: qmp-pcie: add x1e80100 qref supplies

On 5/26/25 3:47 PM, Johan Hovold wrote:

On Thu, May 22, 2025 at 10:03:18PM +0200, Konrad Dybcio wrote:

quoted

On 5/8/25 11:45 AM, Johan Hovold wrote:

quoted

On Thu, May 08, 2025 at 04:50:30PM +0800, Qiang Yu wrote:

quoted

On 5/8/2025 4:20 PM, Johan Hovold wrote:

quoted

quoted

quoted

quoted

This still looks wrong and you never replied to why these supplies
shouldn't be handled by the tcsr clock driver that supplies these
clocks:

	https://lore.kernel.org/lkml/aBHUmXx6N72_sCH9@hovoldconsulting.com/ (local)

quoted

Sorry, I thought Konrad had convinced you.

IIRC, he just said you guys were told to add the QREF supply to the PHY.
That's not an argument.

quoted

If the TCSR driver manages these supplies, would it be possible for tscr
driver to recognize when it needs to turn vdda-qref on or off for a
specific PCIe port?

Sure, just add a lookup table to the driver and enable the required
supplies when a ref clock is enabled.

As I mentioned in the other thread, the T14s has the following QREF
supplies:

	
	VDD_A_QREFS_1P2_A
	VDD_A_QREFS_1P2_B

	VDD_A_QREFS_0P875_A
	VDD_A_QREFS_0P875_B
	VDD_A_QREFS_0P875_0
	VDD_A_QREFS_0P875_2
	VDD_A_QREFS_0P875_3

and it's not clear how these maps to the various consumer ref clocks,
including the PCIe ones:

	#define TCSR_PCIE_2L_4_CLKREF_EN
	#define TCSR_PCIE_2L_5_CLKREF_EN
	#define TCSR_PCIE_8L_CLKREF_EN
	#define TCSR_PCIE_4L_CLKREF_EN

That mapping can be done by the TCSR clock driver (which would also take
care of the 1.2 V supplies).

So we had an internal discussion about this and while it may work, it
would only do so for some SoCs, and maybe only on the surface, as the
wiring behind it is rather peculiar..

Care to expand on why it cannot be made to work generally?

"-ENODATA".. many connections are difficult to unambiguously decipher

Also, what would the mapping of the above QREF supplies to PCIe PHYs
even look like?

I'm not sure I have a clear answer..

quoted

Plus, not all QREF consumers have a clock expressed in TCSR as of
right now.

Is that because there is no corresponding bit in the TCSR or simply
because it has not been described yet?

Unfortunately, the former.. Some IPs have a non-TCSR ref clock and
some are presumably implicitly fed by BI_TCXO

Konrad