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

[Albert ARIBAUD]

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

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

Still, the drivers would be full of 'KWxxx" and "kwxxx" symbols of which
many are not kirkwood-specific actually. In order for these drivers to
compile with an orion5x SoC, I would have to adopt kirkwood names in the
orion5x code, which I don't like as much as I would like fixing the
symbols to make them marvell-, not kirkwood-, specific.

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.