devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Russell King <linux@arm.linux.org.uk>,
	Sascha Hauer <kernel@pengutronix.de>,
	Mike Turquette <mturquette@ti.com>
Subject: Re: [RFC v2 7/9] arm/dt: Common plat-versatile support for icst and sp804 based system clocks
Date: Tue, 17 Jan 2012 16:02:20 -0600	[thread overview]
Message-ID: <4F15EFEC.1000907@gmail.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17801D2363@HQMAIL01.nvidia.com>

On 01/17/2012 03:05 PM, Stephen Warren wrote:
> Grant Likely wrote at Monday, December 12, 2011 3:02 PM:
> ...
>> diff --git a/arch/arm/plat-versatile/clock.c b/arch/arm/plat-versatile/clock.c
> ...
>> +void __init versatile_dt_icst_clk_setup(struct device_node *np)
>> +{
>> +	const struct of_device_id *match;
>> +	struct icst_of_clk *icst;
>> +	const struct icst_params *params;
>> +	u32 ref, vd_range[2], rd_range[2], vco_offset, lock_offset;
>> +	__iomem void * base;
>> +
>> +	/*
>> +	 * Only try to drive clocks that we know how to control.
>> +	 * ie. attached to an ARM Versatile block of system registers
>> +	 */
>> +	if (!of_device_is_compatible(np->parent, "arm,versatile-sys-regs"))
>> +		return;
> ...
>> +	base = of_iomap(np->parent, 0);
> 
> Is this pattern (that of "re-using" a parent node's registers) something
> legitimate that you'd expect to see wide-spread use?
> 

I don't think there is any clear direction for this. Probably doesn't
matter too much because it is typically things closely tied to a
particular SOC. If there's a whole bunch of random bits, it's not likely
to be reused on another SOC. If you can put registers into separate
nodes which are distinct functions even if you have multiple nodes
within a 4KB page you should.

> I ask because Tegra's CAR (Clock And Reset) HW module controls all the
> clocks in the system. The registers for the various clocks are often
> inter-mingled, so it's not possible to give each clock a node with a
> reg property, since they'd all overlap and conflict. Instead, should we
> do something like the following, coupled with the above pattern in the
> per-clock drivers:
> 
> car@60006000 {
>     compatible = "nvidia,tegra20-car";
>     reg = < 0x60006000 0x1000 >;
> 
>     osc@0 {
>         compatible = "nvidia,tegra20-clk-osc";
>     };
>     pll_p@1 {
>         compatible = "nvidia,tegra20-clk-pll";
>         pll_id = <0>;
>     };
>     pll_c@2 {
>         compatible = "nvidia,tegra20-clk-pll";
>         pll_id = <1>;
>     };
>     ...
> };

This is roughly how I'm doing clocks as a sub-node of the clock module.

> 
> Similar, we have many "peripheral" clocks; leaf nodes that are the clocks
> for UART, I2C, SPI, ... that are all controlled in a very similar fashion.
> I can see a couple of alternative ways of representing this:
> 
> a)
> 
> One big node with a ton of clock inputs and outputs:
> 
>     periphclk {
>         compatible = "nvidia,tegra20-clk-periphs";
>         #clock-cells = <1>;
>         /*
>          * This ends up listing almost all clocks in the system;
>          * most are usable as a source for /some/ peripheral clock
>          */
>         clocks = <&pll_p 0> <&pll_c 0> <&pll_m 0 ...>;
>         clock-names = "pll_p", "pll_c", "pll_m", ...;
>         /* And there are maybe 50 of these */
>         clock-output-names = "uart1", "uart2", "i2c1", "i2c2", "spi1", ...;
>     };
> 
> Simon Glass proposed something similar to this on the U-Boot mailing
> list for Tegra's peripheral clocks (since he's working on upstreaming
> Tegra USB support and adding device tree at the same time, and needs
> to parameterize clock IDs in the device tree, since he's not using
> AUXDATA). I'm worried that the huge number of peripheral clocks in the
> above binding would be unwieldy. I'm also unclear how to know which of
> the "clock-names" is the parent for each of the "clock-output-names",
> or if this isn't something the current clock bindings are supports to
> address. Each peripclk is an independent mux, divider, and gate.
> 

Both *-names properties are completely optional. Matching is typically
done by node and phandles rather than name strings. But without names it
is harder to know which clock a number in the cell is referring to as
clocks typically aren't documented that way as opposed to interrupts.

> b)
> 
> A node for each peripheral clock:
> 
>     uart1@0 {
>         compatible = "nvidia,tegra20-clk-uart";
>         clocks = <&pll_p 0>;
>         clock-names = "clk";
>     };
> 
>     uart2@1 {
>         compatible = "nvidia,tegra20-clk-uart";
>         clocks = <&pll_p 0>;
>         clock-names = "clk";
>     };
> 
>     i2s@2 {
>         compatible = "nvidia,tegra20-clk-i2s";
>         clocks = <&audio_clk 0>;
>         clock-names = "clk";
>     };
> 
> etc.
> 
> Thanks for cluing me in!

Either way is fine. I think the former is probably better if there are a
huge number of clocks.

Rob

  reply	other threads:[~2012-01-17 22:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 22:02 [RFC v2 1/9] arm/versatile*: merge all versatile struct clk definitions Grant Likely
2011-12-12 22:02 ` [RFC v2 5/9] dt/clock: Add handling for fixed clocks and a clock node setup iterator Grant Likely
     [not found]   ` <1323727329-4989-5-git-send-email-grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
2011-12-15 15:19     ` Shawn Guo
2011-12-12 22:02 ` [RFC v2 7/9] arm/dt: Common plat-versatile support for icst and sp804 based system clocks Grant Likely
     [not found]   ` <1323727329-4989-7-git-send-email-grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
2012-01-17 21:05     ` Stephen Warren
2012-01-17 22:02       ` Rob Herring [this message]
2012-01-17 22:59       ` Grant Likely
2011-12-12 22:02 ` [RFC v2 8/9] dt/arm: versatile add clock parsing Grant Likely
     [not found] ` <1323727329-4989-1-git-send-email-grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
2011-12-12 22:02   ` [RFC v2 2/9] arm/versatile*: Consolidate clk_ops and setvco implementations Grant Likely
2011-12-12 22:02   ` [RFC v2 3/9] of: Add of_property_match_string() to find index into a string list Grant Likely
2011-12-12 22:02   ` [RFC v2 4/9] of: add clock providers Grant Likely
     [not found]     ` <1323727329-4989-4-git-send-email-grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
2011-12-12 23:29       ` Jamie Iles
2011-12-13 17:54         ` Grant Likely
2011-12-13 18:01           ` Rob Herring
2011-12-13 18:03             ` Grant Likely
2011-12-15 13:51           ` Shawn Guo
     [not found]             ` <20111215135129.GA2831-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-12-15 14:23               ` Rob Herring
2011-12-15 15:13                 ` Shawn Guo
     [not found]                   ` <20111215151335.GB2831-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-12-15 17:37                     ` Grant Likely
2012-01-10 21:33       ` Jamie Iles
2012-01-12  4:46         ` Grant Likely
2012-01-12 10:07           ` Jamie Iles
2012-01-12 18:44             ` Turquette, Mike
2012-01-12 19:16               ` Grant Likely
     [not found]           ` <CACxGe6vqb8AZcZb5WMvfmLsUZH7=SEtBrJCSfsFmDYpKX42MzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-13 12:47             ` Shawn Guo
2012-01-14  4:30               ` Turquette, Mike
2012-01-14  5:40                 ` Shawn Guo
2012-01-13 13:50       ` Shawn Guo
     [not found]         ` <20120113135036.GC17029-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-01-13 14:05           ` Rob Herring
     [not found]             ` <4F103A21.1050403-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-01-13 14:38               ` Shawn Guo
2012-01-17 20:44     ` Stephen Warren
2012-01-17 22:47       ` Grant Likely
2012-01-17 23:37         ` Turquette, Mike
     [not found]           ` <CAJOA=zMgGsZKGQ-EfSnXDY_WoFrzG6XPZtuxANFKqdL8CAaYrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-17 23:49             ` Grant Likely
2012-01-18  0:05             ` Stephen Warren
2011-12-12 22:02   ` [RFC v2 6/9] arm/dt: add devicetree support to sp804 timer support Grant Likely
2011-12-12 23:54     ` Rob Herring
     [not found]       ` <4EE69446.2060009-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-12-13  0:29         ` Grant Likely
2011-12-12 22:02   ` [RFC v2 9/9] arm/highbank: Use clock binding common support code 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=4F15EFEC.1000907@gmail.com \
    --to=robherring2@gmail.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mturquette@ti.com \
    --cc=swarren@nvidia.com \
    /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).