[U-Boot] [PATCH 0/7] Remove individual I2C commands and cleanup

[Heiko Schocher]

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