Re: [PATCH RFC 3/4] clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper

[Konrad Dybcio]

On 4/17/26 11:39 AM, Manivannan Sadhasivam wrote:
> On Mon, Apr 13, 2026 at 01:18:16PM +0200, Konrad Dybcio wrote:
>> On 4/13/26 9:06 AM, Qiang Yu wrote:
>>> On Thu, Apr 09, 2026 at 08:19:41AM -0500, Bjorn Andersson wrote:
>>>> On Wed, Apr 01, 2026 at 09:47:38PM -0700, Qiang Yu wrote:
>>>>> On Wed, Apr 01, 2026 at 10:05:12PM +0530, Taniya Das wrote:
>>>>>> On 4/1/2026 12:05 PM, Qiang Yu wrote:
>>>>>>> diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
>>>> [..]
>>>>>>> +static const char * const tcsr_pcie_4_regulators[] = {
>>>>>>> +	"vdda-refgen-0p9",
>>>>>>> +	"vdda-refgen-1p2",
>>>>>>> +	"vdda-qreftx1-0p9",
>>>>>>> +	"vdda-qrefrpt0-0p9",
>>>>>>> +	"vdda-qrefrpt1-0p9",
>>>>>>> +	"vdda-qrefrpt2-0p9",
>>>>>>> +	"vdda-qrefrx2-0p9",
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> TCSR clock refs are just not for PCIe alone, they would have supplies
>>>>>> for all the ref clocks. These supplies can also be shared across other
>>>>>> clock refs. I think it is not the correct way to handle the supplies, as
>>>>>> TCSR does not have the complete supplies map.
>>>>>>
>>>>> We have complete supplies map. You can get it on ipcatlog. Here is example
>>>>> for other instances eg USB and EDP:
>>>>> - Glymur (eDP): CXO PAD -> TX0 -> RPT0 -> RX0 -> eDP
>>>>> - Glymur (USB4_2): CXO PAD -> TX0 -> RPT0 -> RPT1 -> RX1 -> USB4_2
>>>>> - Glymur (USB3): CXO PAD -> TX0 -> RPT3 -> RPT4 -> RX4 -> USB3_SS3
>>>>>
>>>>> I only add supplies for PCIe in this series because USB and EDP vote these
>>>>> LDO in their PHY driver. They can remove them in PHY dts node and add same
>>>>> regulator list here.
>>>>>
>>>>
>>>> The regulators are reference counted. Can't we add the USB and eDP
>>>> handling here as well now, and then after they are voted here we remove
>>>> them from the PHY?
>>>>
>>>
>>> For USB, I’m not yet sure which tcsr_*_clkref_en each USB instance in the
>>> QREF diagram is tied to. I need to confirm that mapping first, I'm
>>> checking with Wesley Cheng.
>>
>> I think on at least some platforms the reference clock for the primary
>> USB controller is not sw-controllable (so we wouldn't get a handle to
>> toggle the regulator this way).. please check that
>>
> 
> I would suggest we move forward with atleast PCIe regulators for now. Since USB
> and eDP are voting for these regulators on their own, we can work with relevant
> teams later to switch to this model and this is not going to cause any
> regression for them.

I think we can do that, yeah

Konrad