Message-ID: <20111109114936.GL16886@pengutronix.de>
Date:	Wed, 9 Nov 2011 12:49:36 +0100
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	"Cousson, Benoit" <b-cousson@...com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss@...ts.ozlabs.org,
	Rob Herring <rob.herring@...xeda.com>,
	Sascha Hauer <kernel@...gutronix.de>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 6/8] of: add clock providers

On Wed, Nov 09, 2011 at 12:23:25PM +0100, Cousson, Benoit wrote:
> On 11/9/2011 10:13 AM, Sascha Hauer wrote:
> >On Tue, Nov 08, 2011 at 06:19:41PM -0700, Grant Likely wrote:
> 
> [...]
> 
> >>+Sources of clock signal can be represented by any node in the device
> >>+tree.  Those nodes are designated as clock providers.  Clock consumer
> >>+nodes use a phandle and clock specifier pair to connect clock provider
> >>+outputs to clock inputs.  Similar to the gpio specifiers, a clock
> >>+specifier is an array of one more more cells identifying the clock
> >>+output on a device.  The length of a clock specifier is defined by the
> >>+value of a #clock-cells property in the clock provider node.
> >>+
> >>+[1] http://patchwork.ozlabs.org/patch/31551/
> >>+
> >>+==Clock providers==
> >>+
> >>+Required properties:
> >>+#clock-cells:	   Number of cells in a clock specifier; typically will be
> >>+		   set to 1
> >>+
> >>+Optional properties:
> >>+clock-output-name: Recommended to be a list of strings of clock output signal
> >>+		   names indexed by the first cell in the clock specifier.
> >>+		   However, the meaning of clock-output-names is domain
> >>+		   specific to the clock provider, and is only provided to
> >>+		   encourage using the same meaning for the majority of clock
> >>+		   providers.  This format may not work for clock providers
> >>+		   using a complex clock specifier format.  In those cases it
> >>+		   is recommended to omit this property and create a binding
> >>+		   specific names property.
> >
> >If the clock-output-name property is omitted, does this mean a clock
> >provider only has a single output or does it mean that it's not known
> >how many clock outputs a provider actually has?
> 
> Allowing several outputs for a single clock node might lead to a lot
> of confusion. What will be the meaning of a clock rate if you have
> several outputs at different frequency?
> I think it will be better to define a clock node as a single source
> of clock. If several outputs are needed, then we should define
> several clock nodes.
> If we let a clock node be any kind of big clock blob, we will never
> be able to define some generic reusable clock node API. Everybody
> will define its own custom clock blobs.

Generally +1. I asked myself the same question whether it's a good thing
to allow a node to have multiple clocks. For i.MX I can say that I don't
need this and that I do not intend to use this feature. Grants concerns
about this are that the clock part of the device tree might explode when
we put each and every clock into the devicetree, so he wants to allow
bigger blobs of multiple clocks.

My impression gets more and more that we either put the clock tree in the
devicetree or we do not do it, but there's not much room in between.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists