On Friday 24 April 2009, Hugo Villeneuve wrote:
I would suggest renaming (or adding) CONFIG_SOC_DM6446 to CONFIG_SOC_DM644x
The updated patchset I sent includes CONFIG_SOC_DM644X:
http://lists.denx.de/pipermail/u-boot/2009-April/051051.html
I decided to keep the "X" uppercase for consistency with other CONFIG_* symbols, and Linux.
(Note: that series of five patches goes with two patches which seem not to have merged yet:
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
Given those, the GIT tree would be one patch away from basic dm355 evm support.)
and also introducing CONFIG_SOC_DM35x,
As explained in
http://lists.denx.de/pipermail/u-boot/2009-April/051052.html
That's not a good idea. DM357 is *very* different, while DM335 is just a DM355 without the MPEG/JPEG coprocessor. So again I decided to do exactly what Linux is doing there: use a DM355 conditional, and cope with other chips in that family later, if/when needed.
so that we don't have to add a switch statement with all the variants inside one family.
You mean, inside the "psc.c" code which is really not generic PSC stuff but is really SoC-specific device setup code? That's why I took the approach you see in those two patches above: dm644x.c has the SoC-specific bits (and dm355.c), while psc.c keeps the generic bits.