[U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?

[Prafulla Wadaskar]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Monday, November 02, 2009 3:34 PM
> To: Prafulla Wadaskar
> Cc: u-boot at lists.denx.de; Tom
> Subject: Re: [U-Boot] Best way of making some drivers common 
> across kirkwood and orion5x SoCs?
> 
> Prafulla Wadaskar a écrit :
> 
> > Dear Albert
> > 
> > I propose the following strategy for this- For orion- let's follow
> > the standard development strategy used for ARM architectures
> > including Kirkwood. Since orion and kirkwood has lot of similarities
> > but when both these will evolve for there entire supports there will
> > be problems resulting code complexity.
> > 
> > So My suggestion is- let's develop orion as separate ARM SOC family
> > as kirkwood.
> 
> This is what I intend to do, so that's fine with me.
> 
> > Some of Kirkwood drivers can be directly used with Orion, 
> that can be
> > addressed through makefiles as we used NS16550 Serial support in
> > Kirkwood. SOC specific configuration in the common drivers (for ex.
> > Egiga) can always be addressed through individual <asm/arch/*.h>
> 
> Agreed on reusing the drivers; again, that is what I intend to do.
> 
> Thus the only issue left is that the shared drivers (egiga, ehci, I2C,
> gpio and, to a lesser extent, serial) #include the kirkwood.h file and
> use kirkwood-defined symbols (e.g. KW_UART0_BASE) which ties 
> them to the
> kirkwood soc -- purely syntactically, as these symbols for 
> the most part
> are not actually kirkwood-specific.
> 
> The #include part I can handle with something like
> 
> #if defined (CONFIG_KIRKWOOD)
> #include <asm/arch/kirkwood.h>
> #elif defined (CONFIG_ORION5X)
> #include <asm/arch/orion5x.h>
> #else
> #error egiga.c needs either CONFIG_KIRKWOOD or CONFIG_ORION5X.
> #endif

This is correct approach.

> 
> in each driver, so yes, I can live without the 'soc.h' file renaming.

With above reference, you should be,
because it will come from include/asm/arch-<soc>/ that will be different in both the cases.

> 
> Still, the drivers would be full of 'KWxxx" and "kwxxx" 
> symbols of which
> many are not kirkwood-specific actually.

Any way, those are not even orion specific nor Marvell specific.
Those are related to the functionality supported by SOCs that may be customized by each SOC

> In order for these drivers to
> compile with an orion5x SoC, I would have to adopt kirkwood 
> names in the

What harm in this? 

> orion5x code, which I don't like as much as I would like fixing the
If you see kernel code even there you can see kirkwood call from Orion drivers and vice versa.

> symbols to make them marvell-, not kirkwood-, specific.

This will not solve the root problem, what about some non marvell SoC have same h/w and want to reuse the code? Do we again change the suffixes? (kirkwood re-used external serial driver adopting external definitions).

I suggest here to adopt kw symbols in Orion.
This would make it clear for anybody that kirkwood code is reused by orion.
With this kirkwood drives will be untouched.

While doing this reuse activity, if we find something blocking, certainly we should address that, but let's avoid changing identity of drivers.

Regards..
Prafulla . .

> 
> Note that such fixing is rather trivial (tens of lines in the source
> code, basically search and replace) and binary-invariant (I 
> have patches
> for these already that I can post for review upon request).
> 
> > It is always better to break down the entire work in the small
> > pieces, it's easier to digest them faster :-)
> 
> Fine!
> 
> Amicalement,
> -- 
> Albert.
>