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

[Prafulla Wadaskar]

Copying Tom
I will replay latter

Regards..
Prafulla . .

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Saturday, October 31, 2009 2:42 PM
> To: u-boot at lists.denx.de
> Cc: Jean-Christophe PLAGNIOL-VILLARD; Prafulla Wadaskar
> Subject: Best way of making some drivers common across 
> kirkwood and orion5x SoCs?
> 
> Hi,
> 
> I am working on adding mainline support for Orion5x family of Marvell 
> SoCs in U-boot, based on the Kirkwood support already present.
> 
> I believe these are different enough families to justify adding an 
> 'orion5x' SoC along the existing 'kirkwood' one.
> 
> Several kirkwood drivers could actually be reused almost as-is and 
> should thus be shared between both SoC families. For instance, 
> kirkwood_egiga.c and ehci-kirkwood.c would only differ by the 
> number of 
> ports and kirkwood_i2c.c could be reused as-is.
> 
> However, these drivers have hard-coded numbers of ports, and 'hard' 
> references to 'kirkwood.h' for their register definitions. 
> Making them 
> cross-SoC would require moving the numbers of ports to some 
> SoC-specific 
> header file, and that this header file *not* be named after a 
> specific SoC.
> 
> I've searched for a layer between CPU and Core where cross-SoC code 
> could fit, but I haven't seen one, and I don't think one 
> would be needed.
> 
> Instead, I have thought of replacing the #include "kirkwood.h" with a 
> #include "soc.h", where soc.h would exist in both SoC's header files 
> include/asm-arm/arch-kirkwood and include/asm-arm/arch-orion5x. This 
> soc.h file would either include the specific soc header file 
> (kirkwood.h 
> or orion5x.h) or, better yet, be a symlink to it, or better again, 
> replace it.
> 
> This could be done in a two-step approach, each step being one commit.
> 
> 1) introduce "soc.h" by:
> 
> - 1a) renaming, symlinking or including kirkwood.h into soc.h and 
> changing kirkwood drivers that #include "kirkwood.h" accordingly;
> 
> - 1b) turning all kirkwood-specific namings in these kirkwood drivers 
> into marvell-non-soc-specific ones (remove "KW_" prefixes and such).
> 
> (steps 1a and 1b are independent)
> 
> 2) add orion5x support with its own "soc.h" file.
> 
> Would this approach be clean enough to be considered for inclusion in 
> mainline?
> 
> Amicalement,
> -- 
> Albert.
>