Copying Tom I will replay latter
Regards.. Prafulla . .
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Saturday, October 31, 2009 2:42 PM To: u-boot@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.
- 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)
- add orion5x support with its own "soc.h" file.
Would this approach be clean enough to be considered for inclusion in mainline?
Amicalement,
Albert.