From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
Date: Wed, 11 Mar 2015 14:13:59 +0100 [thread overview]
Message-ID: <2233058.m8xh0sUU5j@wuerfel> (raw)
In-Reply-To: <CAB3XZEfnZbZqH95suJ9n39aZRr8kxPdj2HZuWKMvQtYmXe3QEQ@mail.gmail.com>
On Wednesday 11 March 2015 14:12:54 Eliad Peller wrote:
> On Wed, Mar 11, 2015 at 1:34 PM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
> > I think that patch [0] should not be needed since for external clocks,
> > the IP providing the clocks should have its own clock driver and for
> > internal clocks, a property should be used instead as you said.
> >
> >> If there is no external clock provider for this chip and the clocks
> >> are provided by the device itself, then all we need is a clock-frequency
> >> property in the device node.
> >>
> >
> > Agreed, IIUC Luciano wanted to expose the internal clocks by
> > registering in the common clock framework but if those clocks are not
> > really accessible from outside the wlan chip, then I also think that a
> > device node property should be used instead.
> >
> how should i describe multiple clock-frequency properties (there are 2
> relevant clocks) in this case?
>
> does something like the following makes sense?
>
> wlcore: wlcore at 2 {
> ...
> refclock: refclock {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <38400000>;
> };
> }
I would put that clock node on the top level of the DT, as you are
describing an external clock input here, but other than that, it looks
good.
I would do the binding in a way that mandates either a "clocks"
reference to an external clock provider in case of a XTAL or
a "clock-frequency" property. In the first case, you can use
the "clock-names" property to identify the "ref" and "txco"
clock inputs, in the second case we could either decide
to have a single property with two cells, or have named
properties like
wlcore at 2 {
interrupts = < ... >;
tcxo-clock-frequency = <38400000>;
ref-clock-frequency = <19200000>;
}
I don't know which combinations are possible here. I did notice
that most of the references in the board hacks use '0' as the
tcxo clock value, which happens to be the same as
WL12XX_TCXOCLOCK_19_2, but could also meant that no tcxo clock
is used.
Arnd
next prev parent reply other threads:[~2015-03-11 13:13 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-09 15:36 [PATCH v5 1/3] dt: bindings: add wl18xx wireless device Eliad Peller
2015-03-09 15:36 ` [PATCH v5 2/3] wl18xx: add basic device-tree support Eliad Peller
2015-03-09 19:47 ` Arnd Bergmann
2015-03-11 0:34 ` Javier Martinez Canillas
2015-03-11 9:51 ` Arnd Bergmann
2015-03-11 10:05 ` Javier Martinez Canillas
2015-03-11 10:32 ` Arnd Bergmann
2015-03-11 11:50 ` Eliad Peller
2015-03-09 15:36 ` [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings Eliad Peller
2015-03-09 19:50 ` Arnd Bergmann
2015-03-09 21:03 ` Eliad Peller
2015-03-09 22:49 ` Tony Lindgren
2015-03-10 11:00 ` Eliad Peller
2015-03-10 14:11 ` Arnd Bergmann
2015-03-10 14:28 ` Tony Lindgren
2015-03-10 15:48 ` Arnd Bergmann
2015-03-10 15:55 ` Tony Lindgren
2015-03-10 14:31 ` Eliad Peller
2015-03-10 15:52 ` Arnd Bergmann
2015-03-10 16:11 ` Eliad Peller
2015-03-10 16:18 ` Tony Lindgren
2015-03-10 17:01 ` Eliad Peller
2015-03-10 17:35 ` Tony Lindgren
2015-03-10 19:49 ` Arnd Bergmann
2015-03-11 1:00 ` Javier Martinez Canillas
2015-03-11 9:53 ` Arnd Bergmann
2015-03-11 11:34 ` Javier Martinez Canillas
2015-03-11 12:12 ` Eliad Peller
2015-03-11 13:13 ` Arnd Bergmann [this message]
2015-03-11 12:40 ` Arnd Bergmann
2015-03-11 13:07 ` Javier Martinez Canillas
2015-03-11 13:17 ` Arnd Bergmann
2015-03-11 13:21 ` Javier Martinez Canillas
2015-03-11 13:38 ` Eliad Peller
2015-03-11 15:11 ` Tony Lindgren
2015-03-10 14:34 ` Sekhar Nori
2015-03-10 15:54 ` Arnd Bergmann
2015-03-11 0:28 ` Javier Martinez Canillas
2015-03-11 1:19 ` Javier Martinez Canillas
2015-03-11 11:59 ` Eliad Peller
2015-03-11 12:07 ` Javier Martinez Canillas
2015-03-11 11:54 ` Eliad Peller
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=2233058.m8xh0sUU5j@wuerfel \
--to=arnd@arndb.de \
--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