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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
