[PATCHv9 30/43] ARM: dts: am33xx clock data
Tero Kristo
t-kristo at ti.com
Mon Oct 28 06:12:11 EDT 2013
On 10/28/2013 11:59 AM, Jan Lübbe wrote:
> On Sat, 2013-10-26 at 15:46 +0300, Tero Kristo wrote:
>> On 10/26/2013 03:36 AM, Jan Lübbe wrote:
>>> On Fri, 2013-10-25 at 18:57 +0300, Tero Kristo wrote:
>>>> + mcasp0_fck: mcasp0_fck {
>>>> + #clock-cells = <0>;
>>>> + compatible = "fixed-factor-clock";
>>>> + clocks = <&sys_clkin_ck>;
>>>> + clock-mult = <1>;
>>>> + clock-div = <1>;
>>>> + };
>>>> +
>>>> + mcasp1_fck: mcasp1_fck {
>>>> + #clock-cells = <0>;
>>>> + compatible = "fixed-factor-clock";
>>>> + clocks = <&sys_clkin_ck>;
>>>> + clock-mult = <1>;
>>>> + clock-div = <1>;
>>>> + };
>>>
>>> What is you use case for these clocks with a fixed factor of 1? Wouldn't
>>> it be simpler to just use sys_clkin_ck from the devices?
>>
>> This is just kind of a dummy clock node for the driver use, so that it
>> is simpler for them to find their clocks. If these are dropped, the
>> drivers need to know that instead of their old own mcaspX_fck, they now
>> need to directly connect to sys_clkin_ck. This also allows to track
>> usecounts for the clocks better, if you don't have the mcaspX_fck:s for
>> example, you will just have a usecount of 25 for the sys_clkin_ck, but
>> don't really know who is using it. Also, other SoCs most likely have the
>> same name in use, so just to keep the clock data compatible across SoCs.
>>
>> These files are also completely autogenerated from the existing clock
>> data under mach-omap2, and these nodes exist there.
>>
>> But yea, no hard requirement.
>
> We shouldn't add dummy clocks to simplify debugging, maybe we need some
> user tracking in the core clk code?
Yea might be good to have something like this as configurable option in
the future, so you would know who has enabled a certain clock. Currently
clock APIs don't really provide way to tell users apart from each other.
Mike, any thoughts on this?
>
> As there are only few of these factor 1 clocks, I'm fine with keeping
> them for consistency here.
Thanks. :)
-Tero
More information about the linux-arm-kernel
mailing list