From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] clocktree representation in the devicetree
Date: Mon, 17 Oct 2011 17:02:05 +0200 [thread overview]
Message-ID: <201110171702.05319.arnd@arndb.de> (raw)
In-Reply-To: <20111017102921.GA18141@pengutronix.de>
On Monday 17 October 2011, Sascha Hauer wrote:
> The following is an attempt to represent the clocktree of a i.MX53 in
> the devicetree. I created this to see how it would look like and to
> start a discussion whether we want to move in this direction or not.
Very good, thanks for getting this started!
> Some things to consider:
>
> - It seems to be very flexible. A board can customize the clock tree
> by just adding some clk-parent=<phandle> properties to the muxers.
> - clocks can easily be associated with devices.
>
> but:
>
> - The following example registers 127 new platform devices and it's
> not even complete. This adds significant overhead to initialization.
I don't understand enough about the clock trees to understand if the
dts representation is good, but it I don't see a reason to represent
it as lots of platform devices in linux. We can have lots of device_nodes
in the device tree that are not a platform_device but we can still
access them through the of_*() functions. Ideally, we would encapsulate
all the clock tree parsing in the clk subsystem and provide high-level
interfaces to clkdev drivers from there.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: devicetree-discuss@lists.ozlabs.org,
Grant Likely <grant.likely@secretlab.ca>,
Richard Zhao <richard.zhao@freescale.com>,
Shawn Guo <shawn.guo@linaro.org>,
linux-arm-kernel@lists.infradead.org,
Mike Turquette <mturquette@ti.com>
Subject: Re: [RFC] clocktree representation in the devicetree
Date: Mon, 17 Oct 2011 17:02:05 +0200 [thread overview]
Message-ID: <201110171702.05319.arnd@arndb.de> (raw)
In-Reply-To: <20111017102921.GA18141@pengutronix.de>
On Monday 17 October 2011, Sascha Hauer wrote:
> The following is an attempt to represent the clocktree of a i.MX53 in
> the devicetree. I created this to see how it would look like and to
> start a discussion whether we want to move in this direction or not.
Very good, thanks for getting this started!
> Some things to consider:
>
> - It seems to be very flexible. A board can customize the clock tree
> by just adding some clk-parent=<phandle> properties to the muxers.
> - clocks can easily be associated with devices.
>
> but:
>
> - The following example registers 127 new platform devices and it's
> not even complete. This adds significant overhead to initialization.
I don't understand enough about the clock trees to understand if the
dts representation is good, but it I don't see a reason to represent
it as lots of platform devices in linux. We can have lots of device_nodes
in the device tree that are not a platform_device but we can still
access them through the of_*() functions. Ideally, we would encapsulate
all the clock tree parsing in the clk subsystem and provide high-level
interfaces to clkdev drivers from there.
Arnd
next prev parent reply other threads:[~2011-10-17 15:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 10:29 [RFC] clocktree representation in the devicetree Sascha Hauer
2011-10-17 10:29 ` Sascha Hauer
2011-10-17 15:02 ` Arnd Bergmann [this message]
2011-10-17 15:02 ` Arnd Bergmann
2011-10-17 19:12 ` Sascha Hauer
2011-10-17 19:12 ` Sascha Hauer
2011-10-17 17:01 ` Rob Herring
2011-10-17 17:01 ` Rob Herring
2011-10-17 18:43 ` Sascha Hauer
2011-10-17 18:43 ` Sascha Hauer
2011-10-17 23:11 ` Rob Herring
2011-10-17 23:11 ` Rob Herring
2011-10-18 7:16 ` Sascha Hauer
2011-10-18 7:16 ` Sascha Hauer
2011-10-18 15:35 ` Rob Herring
2011-10-18 15:35 ` Rob Herring
2011-10-20 7:28 ` Sascha Hauer
2011-10-20 7:28 ` Sascha Hauer
2011-11-08 18:33 ` Grant Likely
2011-11-08 18:33 ` 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=201110171702.05319.arnd@arndb.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.