From: Mike Turquette <mturquette@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>, Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus WALLEIJ <linus.walleij@stericsson.com>,
Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree
Date: Tue, 11 Jun 2013 13:28:21 -0700 [thread overview]
Message-ID: <20130611202821.8816.86653@quantum> (raw)
In-Reply-To: <201306042252.03340.arnd@arndb.de>
Quoting Arnd Bergmann (2013-06-04 13:52:03)
> On Tuesday 04 June 2013, Linus Walleij wrote:
> > The whole thing is very different from other DT clock things
> > I've seen, usually you add a compatible node for each
> > clock type, and a node for each physical gate. But there
> > may be several ways to skin this cat...
> >
>
> Based on the IRC discussion we had, I would think that the "prcc" clocks
> would best be represented using multiple clock-cells since you can describe
> them easily a tuple of register index, bit number some way to distinguish
> the two types.
>
> The "prcmu" clocks are harder, and we probably need either a more verbose
> representation using one node per clock there, or have a single node
> for the entire prcmu and not bother to describe them in DT but hardcode
> everything in the source. The current patch does the latter, which is
> easier now but means we cannot simplify the code much in the future
> when we remove ATAGS boot support.
>
> I hope Mike can give some better insight to what his preferences are.
I'm still learning about DT so my inputs should be weighed, measured and
then promptly thrown out. With that said I recently published an RFC to
convert the OMAP4 PRCM clocks to DT and my approach was a single node
per clock.
The register mapping for those clocks is mostly orderly, but not so
orderly that a neat and tidy tuple would suffice. Also the recent MMP
clock series represents many of the clocks as single nodes.
I am not opposed to this design choice and it removes more data from C
files. Some concerns were brought up about impacts to boot time but no
one has quantified that yet.
Regards,
Mike
>
> Arnd
next prev parent reply other threads:[~2013-06-11 20:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1370266965-7901-1-git-send-email-lee.jones@linaro.org>
[not found] ` <1370266965-7901-22-git-send-email-lee.jones@linaro.org>
[not found] ` <1370266965-7901-22-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-06-04 10:57 ` [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree Linus Walleij
2013-06-04 20:52 ` Arnd Bergmann
[not found] ` <201306042252.03340.arnd-r2nGTMty4D4@public.gmane.org>
2013-06-05 8:05 ` Lee Jones
2013-06-11 20:28 ` Mike Turquette [this message]
[not found] ` <CACRpkdaNMR=6JT+pi+9aqOJXW3gK9Yb4hztx3rOiY3c+f3UTRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-12 12:56 ` Grant Likely
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=20130611202821.8816.86653@quantum \
--to=mturquette@linaro.org \
--cc=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srinidhi.kasagar@stericsson.com \
--cc=ulf.hansson@linaro.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).