On Thu Oct 23, 2025 at 1:18 AM CEST, Randolph Sapp wrote:
> On Wed Oct 22, 2025 at 1:23 AM CDT, Michael Walle wrote:
>> Hi,
>>
>>>> Am I correct in my assumption about running clk_get_rate on unprepared clocks
>>>> though? (That it shouldn't be allowed or, if it is, that the result shouldn't be
>>>> cached.)
>>>>
>>> Any follow up to this Michael? I wanted to be sure this was something the
>>> subsystem should allow before I look into further workarounds.
>>
>> I don't know. I'm not that familar with the ccs. My first reaction
>> was that it's asymmetrical that a .set is allowed (and works for
>> tisci) and that .get is not allowed. That way you can't read the
>> hardware clock (or think of a fixed clock, where you want to get the
>> frequency) before enabling it. I could imagine some devices which
>> needs to be configured first, before you might turn the clock on.
>>
>> OTOH Maxime pointed out the comment in the kdoc of clk_get_rate()
>> which clearly states that it's only valid if the clock is on.
>>
>> -michael
>
> Yeah, I still don't like the way we handle clock in firmware but I've already
> been shut down on that front.

TBC, I was talking about the CCS set/get API in general.

-michael

> Regardless, there are quite a few drivers right now that use clk_get_rate prior
> to preparing the clock. If the kdoc reports clk_get_rate is only valid if the
> clock is enabled, should we report a proper warning when this occurs?
>
> - Randolph