From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: John Jacques <john.jacques-M7mHMAq9Yzo@public.gmane.org>,
linuxppc-dev list
<linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
Torez Smith <torez-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
Russell King <rmk-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Subject: Re: ARM clock API to PowerPC
Date: Wed, 12 Aug 2009 18:29:22 +1000 [thread overview]
Message-ID: <1250065762.15143.47.camel@pasglop> (raw)
In-Reply-To: <1250063825.15143.43.camel@pasglop>
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
> - Device-tree: The idea on top of my mind would be to define a
> clock-map property that has the following format:
>
> A list of:
> - zero terminated string clock ID, padded with zeros
> to a cell boundary
> - a phandle to the clock provider
> - a numerical (string ?) ID for that clock within that provider
>
> The core would thus be able to do a search in that list based on the
> clock-id passed in, or if clk_get(dev, NULL), then, use the first one.
Thinking a bit more about that one, mixing strings and numbers in a
property sucks. What about instead:
clock-map is a list of phandle, id
clock-names is an optional list of 0 terminated strings
If there's only one clock, and the ID can be ommited, then the
clock-names property can be ommited completely too. Else, the
entries in clock-names match the entries in clock-map.
It's a bit strange to separate the list into two properties but
I think it will generally suck less than having them mixed, especially
with ASCII representations such as lsprop output.
Cheers,
Ben
next prev parent reply other threads:[~2009-08-12 8:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-12 7:57 ARM clock API to PowerPC Benjamin Herrenschmidt
2009-08-12 8:29 ` Benjamin Herrenschmidt [this message]
2009-08-12 17:31 ` Mitch Bradley
[not found] ` <4A82FC63.7020705-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2009-08-12 21:30 ` Benjamin Herrenschmidt
2009-08-12 11:19 ` Josh Boyer
[not found] ` <20090812111954.GB31596-jnIq6iUNB1CO8iYQgJmm/0EOCMrvLtNR@public.gmane.org>
2009-08-12 13:40 ` Kumar Gala
[not found] ` <4A90486C-8BF5-428C-9FD8-830D822C0D40-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2009-08-12 21:29 ` Benjamin Herrenschmidt
2009-08-13 8:59 ` Li Yang-R58472
[not found] ` <3A45394FD742FA419B760BB8D398F9ED59DE33-bKEhWGtIRUJ4Lp7cDGe+DVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2009-08-14 9:29 ` Benjamin Herrenschmidt
2009-08-14 11:29 ` Guennadi Liakhovetski
[not found] ` <Pine.LNX.4.64.0908141255230.5980-0199iw4Nj15frtckUFj5Ag@public.gmane.org>
2009-08-14 12:07 ` Benjamin Herrenschmidt
2009-08-15 12:43 ` Russell King
[not found] ` <20090815124347.GB16112-f404yB8NqCZvn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2009-08-15 22:18 ` Benjamin Herrenschmidt
2009-08-16 5:09 ` Grant Likely
2009-08-12 12:35 ` Mark Brown
[not found] ` <20090812123551.GC11227-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2009-08-12 21:34 ` Benjamin Herrenschmidt
2009-08-12 21:44 ` Mark Brown
[not found] ` <20090812214444.GA4731-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2009-08-12 21:56 ` Benjamin Herrenschmidt
2009-08-12 22:20 ` Mark Brown
[not found] ` <20090812222031.GC4731-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2009-08-12 22:32 ` Benjamin Herrenschmidt
2009-08-12 23:00 ` Mark Brown
[not found] ` <20090812230023.GB7519-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2009-08-12 23:15 ` Benjamin Herrenschmidt
2009-08-12 22:28 ` Russell King
2009-08-12 22:45 ` Mark Brown
[not found] ` <20090812222843.GA7118-f404yB8NqCZvn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2009-08-12 22:52 ` Benjamin Herrenschmidt
2009-08-12 23:40 ` Russell King
[not found] ` <20090812234048.GB7118-f404yB8NqCZvn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2009-08-12 23:47 ` Benjamin Herrenschmidt
2009-08-13 3:45 ` Benjamin Herrenschmidt
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=1250065762.15143.47.camel@pasglop \
--to=benh-xvmvhmargas8u2djnn8i7kb+6bgklq7r@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=john.jacques-M7mHMAq9Yzo@public.gmane.org \
--cc=linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
--cc=rmk-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=torez-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.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