Hello Peter, Peter Tyser wrote: >>> This patch series removes the "individual" I2C commands (and the >>> CONFIG_I2C_CMD_TREE define) and migrates all boards to the newer >>> "tree style" I2C commands. >>> >>> A small amount of cleanup was performed before and after removing >>> the individual commands. >> Thanks for your work, looks good to me. I make some tests >> with your patches, and if they are OK, I apply your patches to >> u-boot-i2c.git. > > Great, thanks.
Sorry, I had no time for it, but hopefully I am ready with it on monday. >> Hmm.. maybe you can have a look at my posting: >> >> http://lists.denx.de/pipermail/u-boot/2009-March/049506.html >> >> There is a new i2c_core.c file which holds all "common" i2c >> functions, for example the i2c_[set|get]_bus_speed(). I >> think such a file is a better place for it. > > I agree that the concept of having common i2c functions in common file > (and not in cmd_i2c.c) is a good idea. If you want me to rebase my > changes on the i2c multibus_v2 tree let me know and I'll move the > i2c_[set|get]_bus_speed() to i2c_core.c and resubmit. No need for you to do this, because I think, the "new" multibus update must have some time to test, so it takes a while for it to go in main- line. > While we're discussing the i2c commands, another TODO item could be to > transition the new tree-style I2C command to use a cmd_tbl_t instead of > the current ifs/strncmp. Yes, thats right, patches are welcome ;-) >> I wonder I get no response for cleaning up the i2c subsystem ... >> is here no interest in doing such a cleanup? (I think it is >> a necessary step ...) > > My guess would be that people aren't making lots of comments because: > - Most people don't require the new functionality of the i2c subsystem > cleanup with their current hardware, thus they have less of an interest > in critiquing it as it doesn't really affect them. They also don't have > any hardware to test/play with the new features. It maybe affects them, because also "old" hardware with only one I2C driver should be tested, and I have not all boards for testing ... so it would be nice if some boardmaintainers can do also tests with the new i2c subsystem, and give a little feedback ... preferred feedback: "My board works without problems with the new multibus core" ;-) > - Most people are busy working on changes that do affect their hardware, > etc Yes, thats probably the biggest reason. > - It takes more effort to review patches that haven't been posted to the > mailing list Hmm.. sorry for that, but some patches were greater then 100k, because they affected a lot of boards (for example the ppc_4xx i2c driver), so I didn;t post them ... and it is not such a big work to get this patches with git ... but you are right, it is more effort to do this, then just reading an EMail ... > - The original i2c discussion/flameware scared them off:) Yes, maybe. It was a "hard" discussion ... > Anyway, I agree with Jerry that the added functionality of the i2c > subsystem cleanup is good (but can't speak to the implementation), > hopefully the lack of comments mean people haven't found anything too > objectionable in your changes. That sounds like a dream ;-) So I try to hold the to branches in sync with mainline, and maybe I find time to port the missing i2c driver to it, and then I start a second(third) round for it thanks bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
