lkml.org 
[lkml]   [2013]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 3/6] ARM: at91/dt: define sama5d3 clocks
On 09/12/2013 17:48, Arnd Bergmann wrote:
> On Monday 09 December 2013, boris brezillon wrote:
>> Hello Arnd,
>>
>> On 09/12/2013 16:48, Arnd Bergmann wrote:
>>> On Monday 09 December 2013, boris brezillon wrote:
>>>>> You are adding "clock-names" properties in a lot of cases. Are you sure you
>>>>> are using the strings that are documented in the respective device bindings
>>>>> for each name? In a lot of cases, drivers just want an anonymous clock
>>>>> and we don't name them.
>>>> I rechecked it, and almost all drivers call [devm_]clk_get with a
>>>> specific clock
>>>> name, and as a result we must specify the "clock-names" property.
>>>> The only exceptions I found are the spi and PIT (Periodic Interval
>>>> Timer) drivers,
>>>> and "clock-names" property is not defined in these nodes.
>>> Yes, I understood that the *drivers* use the names, but are they actually
>>> documented in the device bindings? If not, it might be better to change the
>>> drivers.
>> We have to keep both clk system working for at91 platform (new CCF based
>> clk implementations and old clk implementations) for two reasons:
>> 1) the new clk implemetations are only compatible with DT enabled boards
>> and some at91 boards are not yet ported to DT.
>> 2) we decided to move to the new clk implementations in multiple steps
>> (one SoC
>> family after another) in order to ease PATCH review.
>>
>> If we change the drivers to avoid specific clock name request
>> ([devm]_clk_get(dev, NULL)),
>> we will have to change the old static clk lookup tables
>> (i.e.
>> http://lxr.free-electrons.com/source/arch/arm/mach-at91/at91sam9g45.c#L226,
>> http://lxr.free-electrons.com/source/arch/arm/mach-at91/at91sam9260.c#L202,
>> ...).
> Yes, that is a bit painful, but we really need to ensure that the drivers
> implement the documented binding. If they don't match we have to either
> review and change all the binding documents, or change the static clock
> tables and the drivers.
>
> Note that I have not checked your binding documents for the devices in
> question. If they already document these names, we don't need to change
> anything.

Are you talking about drivers or clk binding documentation ?
In either cases they're not defined :-), but I'd like to know which
file(s) I
should update.

I'd rather not change the static clock lookup tables, but if you prefer this
approach (and Nicolas agrees), I'll propose a series modifying the drivers
and clk lookup table.

Whatever solution is choosen, I guess I'll have to update the drivers dt
binding documentation anyway ;-).

Best Regards,

Boris

>
> Arnd



\
 
 \ /
  Last update: 2013-12-09 18:21    [W:0.092 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site