From mboxrd@z Thu Jan  1 00:00:00 1970
From: t-kristo@ti.com (Tero Kristo)
Date: Mon, 28 Oct 2013 12:12:11 +0200
Subject: [PATCHv9 30/43] ARM: dts: am33xx clock data
In-Reply-To: <1382954349.11504.213.camel@coredoba.hi.pengutronix.de>
References: <1382716658-6964-1-git-send-email-t-kristo@ti.com>		
 <1382716658-6964-31-git-send-email-t-kristo@ti.com>	
 <1382747784.6200.4.camel@polaris.local> <526BB9A2.2050108@ti.com>
 <1382954349.11504.213.camel@coredoba.hi.pengutronix.de>
Message-ID: <526E387B.7010306@ti.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

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