[PATCH 03/11] dt-bindings: clock: add NXP LPC32xx clock list for consumers

[Arnd Bergmann]

On Friday 20 November 2015 19:58:06 Vladimir Zapolskiy wrote:
> On 20.11.2015 15:56, Arnd Bergmann wrote:
> > On Friday 20 November 2015 03:05:03 Vladimir Zapolskiy wrote:
> >> +
> >> +/* LPC32XX System Control Block clocks */
> >> +#define LPC32XX_CLK_RTC                0
> >> +#define LPC32XX_CLK_DMA                1
> >> +#define LPC32XX_CLK_MLC                2
> >> +#define LPC32XX_CLK_SLC                3
> >> +#define LPC32XX_CLK_LCD                4
> >> +#define LPC32XX_CLK_MAC                5
> >> +#define LPC32XX_CLK_SD         6
> >> +#define LPC32XX_CLK_DDRAM      7
> >> +#define LPC32XX_CLK_SSP0       8
> >> +#define LPC32XX_CLK_SSP1       9
> >> +#define LPC32XX_CLK_UART3      10
> >> +#define LPC32XX_CLK_UART4      11
> >> +#define LPC32XX_CLK_UART5      12
> >> +#define LPC32XX_CLK_UART6      13
> >> +#define LPC32XX_CLK_IRDA       14
> >> +#define LPC32XX_CLK_I2C1       15
> >>
> > 
> > Any chance we can avoid the include file? This is going to make it really
> > hard to merge everything in one merge window with the dependencies between
> > the driver, the bindings and the platform code.
> 
> I see only one option to avoid this commit, namely squash it with the
> CCF driver and merge it before making changes in DTS.
> 
> However I suppose ARM trees won't be synced on clk tree, so probably it
> won't simplify maintainer's work.

I think the best way for this would then be to have one git branch that
contains the binding header, and base the other patches on top of that
branch, for both the changes going into the clk git and arm-soc.

That way, both have the commit we need, but we don't get duplicate
commits when they are both merged into mainline.

> > If there is a way to describe the clocks based on numbers from the
> > data sheet instead of making up your own, that makes life much
> > easier for us.
> 
> There are no any clock numbers in the datasheet, unfortunately.

I was thinking that maybe there would be a logical numbering based
on the register layout, e.g. a tuple of register index and bit position,
but it seems that the mmio area is too irregular to make that easy.

	Arnd