Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

[Linus Walleij]

On Mon, Jun 3, 2013 at 3:42 PM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> In this patch we're populating a clk_data array, one clock per element to
> act as a clk look-up using indexes supplied from Device Tree.
>
> Cc: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

This needs to be patch 1/21 because otherwise the rest of the
stuff is non-bisectable right? It's being broken the first time
you remove auxdata and not fixed until this patch.

The whole thing is very different from other DT clock things
I've seen, usually you add a compatible node for each
clock type, and a node for each physical gate. But there
may be several ways to skin this cat...

Make sure to include devicetree-discuss in the series for
an OS-neutral review opportunity.

Yours,
Linus Walleij

Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

[Arnd Bergmann]

On Tuesday 04 June 2013, Linus Walleij wrote:
> The whole thing is very different from other DT clock things
> I've seen, usually you add a compatible node for each
> clock type, and a node for each physical gate. But there
> may be several ways to skin this cat...
> 

Based on the IRC discussion we had, I would think that the "prcc" clocks
would best be represented using multiple clock-cells since you can describe
them easily a tuple of register index, bit number some way to distinguish
the two types.

The "prcmu" clocks are harder, and we probably need either a more verbose
representation using one node per clock there, or have a single node
for the entire prcmu and not bother to describe them in DT but hardcode
everything in the source. The current patch does the latter, which is
easier now but means we cannot simplify the code much in the future
when we remove ATAGS boot support.

I hope Mike can give some better insight to what his preferences are.

	Arnd

Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

[Lee Jones]

On Tue, 04 Jun 2013, Arnd Bergmann wrote:

> On Tuesday 04 June 2013, Linus Walleij wrote:
> > The whole thing is very different from other DT clock things
> > I've seen, usually you add a compatible node for each
> > clock type, and a node for each physical gate. But there
> > may be several ways to skin this cat...
> > 
> 
> Based on the IRC discussion we had, I would think that the "prcc" clocks
> would best be represented using multiple clock-cells since you can describe
> them easily a tuple of register index, bit number some way to distinguish
> the two types.
> 
> The "prcmu" clocks are harder, and we probably need either a more verbose
> representation using one node per clock there, or have a single node
> for the entire prcmu and not bother to describe them in DT but hardcode
> everything in the source. The current patch does the latter, which is
> easier now but means we cannot simplify the code much in the future
> when we remove ATAGS boot support.

As already discussed, in the PRCMU case I'm going to make 'enum
prcmu_clock {' look like register PRCM_YYCLKEN0_MGT_SET as described
by the design specification, and use that as our indexer.

> I hope Mike can give some better insight to what his preferences are.
> 
> 	Arnd

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

[Mike Turquette]

Quoting Arnd Bergmann (2013-06-04 13:52:03)
> On Tuesday 04 June 2013, Linus Walleij wrote:
> > The whole thing is very different from other DT clock things
> > I've seen, usually you add a compatible node for each
> > clock type, and a node for each physical gate. But there
> > may be several ways to skin this cat...
> > 
> 
> Based on the IRC discussion we had, I would think that the "prcc" clocks
> would best be represented using multiple clock-cells since you can describe
> them easily a tuple of register index, bit number some way to distinguish
> the two types.
> 
> The "prcmu" clocks are harder, and we probably need either a more verbose
> representation using one node per clock there, or have a single node
> for the entire prcmu and not bother to describe them in DT but hardcode
> everything in the source. The current patch does the latter, which is
> easier now but means we cannot simplify the code much in the future
> when we remove ATAGS boot support.
> 
> I hope Mike can give some better insight to what his preferences are.

I'm still learning about DT so my inputs should be weighed, measured and
then promptly thrown out. With that said I recently published an RFC to
convert the OMAP4 PRCM clocks to DT and my approach was a single node
per clock.

The register mapping for those clocks is mostly orderly, but not so
orderly that a neat and tidy tuple would suffice.  Also the recent MMP
clock series represents many of the clocks as single nodes.

I am not opposed to this design choice and it removes more data from C
files.  Some concerns were brought up about impacts to boot time but no
one has quantified that yet.

Regards,
Mike

> 
>         Arnd

Re: [PATCH 21/21] clk: ux500: Supply provider look-up functionality to support Device Tree

[Grant Likely]

On Tue, 4 Jun 2013 12:57:06 +0200, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Jun 3, 2013 at 3:42 PM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> 
> > In this patch we're populating a clk_data array, one clock per element to
> > act as a clk look-up using indexes supplied from Device Tree.
> >
> > Cc: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> 
> This needs to be patch 1/21 because otherwise the rest of the
> stuff is non-bisectable right? It's being broken the first time
> you remove auxdata and not fixed until this patch.
> 
> The whole thing is very different from other DT clock things
> I've seen, usually you add a compatible node for each
> clock type, and a node for each physical gate. But there
> may be several ways to skin this cat...

The design choice made here is perfectly fine by me. There has never
been a requirement to expose every clock as a separate node, and for
SoCs with complex clock control blocks I can certainly appreciate not
wanting to expose how the internal clocks interact out to the device
tree, especially if only the leaf clocks ever get reverenced by device
drivers. As long as there is a driver there that understands the binding
and hands out the correct clock when asked, then this design is great.

g.