Copying Tom I will replay latter Regards.. Prafulla . .
> -----Original Message----- > From: Albert ARIBAUD [mailto:albert.arib...@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. > > 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
