From: b.brezillon@overkiz.com (boris brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/6] ARM: at91/dt: define sama5d3 clocks
Date: Mon, 09 Dec 2013 18:02:21 +0100 [thread overview]
Message-ID: <52A5F79D.9070408@overkiz.com> (raw)
In-Reply-To: <201312091748.58386.arnd@arndb.de>
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
next prev parent reply other threads:[~2013-12-09 17:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-28 14:49 [PATCH v4 0/6] ARM: at91: use new at91 clks for samad3 SoCs Boris BREZILLON
2013-11-28 14:50 ` [PATCH v4 1/6] ARM: at91: prepare sama5 dt boards transition to common clk Boris BREZILLON
2013-11-28 14:50 ` [PATCH v4 2/6] ARM: at91: prepare common clk transition for sama5d3 SoC Boris BREZILLON
2013-11-28 14:50 ` [PATCH v4 3/6] ARM: at91/dt: define sama5d3 clocks Boris BREZILLON
2013-12-09 2:09 ` Arnd Bergmann
2013-12-09 8:43 ` boris brezillon
2013-12-09 15:48 ` Arnd Bergmann
2013-12-09 16:17 ` boris brezillon
2013-12-09 16:48 ` Arnd Bergmann
2013-12-09 17:02 ` boris brezillon [this message]
2013-12-09 21:05 ` Arnd Bergmann
2013-11-28 14:50 ` [PATCH v4 4/6] ARM: at91/dt: define sama5d3xek's main clk frequency Boris BREZILLON
2013-11-28 14:51 ` [PATCH v4 5/6] ARM: at91: move sama5d3 SoC to common clk Boris BREZILLON
2013-11-28 14:52 ` [PATCH v4 6/6] ARM: at91/dt: remove old clk material Boris BREZILLON
2013-12-02 14:35 ` [PATCH v4 0/6] ARM: at91: use new at91 clks for samad3 SoCs Nicolas Ferre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52A5F79D.9070408@overkiz.com \
--to=b.brezillon@overkiz.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).