All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.