Re: [PATCH v3 1/6] dt-bindings: PCI: Add binding for qps615

[Krishna Chaitanya Chundru <quic_krichai@quicinc.com>]

On 11/28/2024 7:38 PM, Dmitry Baryshkov wrote:
> On Thu, Nov 28, 2024 at 06:54:32PM +0530, Manivannan Sadhasivam wrote:
>> On Tue, Nov 26, 2024 at 07:58:16AM +0100, Krzysztof Kozlowski wrote:
>>> On 26/11/2024 07:50, Krishna Chaitanya Chundru wrote:
>>>>
>>>>
>>>> On 11/25/2024 1:10 PM, Krzysztof Kozlowski wrote:
>>>>> On 24/11/2024 02:41, Krishna Chaitanya Chundru wrote:
>>>>>>> ...
>>>>>>>
>>>>>>>> +  qps615,axi-clk-freq-hz:
>>>>>>>
>>>>>>> That's a downstream code you send us.
>>>>>>>
>>>>>>> Anyway, why assigned clock rates do not work for you? You are
>>>>>>> re-implementing legacy property now under different name :/
>>>>>>>
>>>>>>> The assigned clock rates comes in to the picture when we are
>>>>>>> using clock
>>>>>> framework to control the clocks. For this switch there are no
>>>>>> clocks needs to be control, the moment we power on the switch
>>>>>> clocks are enabled by default. This switch provides a mechanism to
>>>>>> control the frequency using i2c. And switch supports only two
>>>>>> frequencies i.e
>>>>>
>>>>>
>>>>> frequency of what, since there are no clocks?
>>>>>
>>>> The axi clock frequency internal to the switch, host can't control
>>>> the enablement of the clocks it can control only the frequency.
>>>>
>>>> we already had a discussion on this on v2[1], and we taught you agreed
>>>> on this property.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/netdev/d1af1eac-f9bd-7a8e-586b-5c2a76445145@codeaurora.org/T/#m3d5864c758f2e05fa15ba522aad6a37e3417bd9f
>>>>
>>>
>>> This points something else. I diged v2 and found many unanswered
>>> questions and unfinished discussion:
>>>
>>
>> The conversation is here:
>> https://lore.kernel.org/linux-arm-msm/20240823094028.7xul4eoiexey5xjm@thinkpad/
>>
>> But there was no explicit agreement on the usage of 'qps615,axi-clk-freq-hz'.
>>
>> If describing the PCI device's internal clock frequency is not applicable, then
>> I'd recommend to change the clock rate in the driver itself based on the number
>> of DSPs enabled (or based on other configuration).
> 
> Sounds like the best approach. Otherwise it's not obvious, what is the
> criteria for selecting this or that clock value.
> 
I will remove this property in next patch and driver code to set this 
frequency in the next patch, we will try to come up with some logic later.

- Krishna chaitanya.
>>
>> - Mani
>>
>> -- 
>> மணிவண்ணன் சதாசிவம்
>