Hello Wolfgang, Wolfgang Denk wrote: > In message <[email protected]> you wrote: >>> Correct. If we are going to rework the Soft-I2C implementation, this >>> should be done for all boards (which is a pretty big action), and >>> probably should be done as part of the "i2c: rework multibus/multi- >>> adapter functionality" changes. >> Hmm... I don;t understand why we must rework all I2C Soft implementations. >> Just boards, who must/want call functions instead of direct using >> the I2C_XXX macros, can use this patch ... existing boards are > > Maybe I miss the point - but what is the problem with "direct using > the I2C_XXX macros"? You can always #define the I2C_XXX macros sucht > hat they indeed call the required functions, right? I really don;t get > the point.
The problem is actual (if I see this right ;-) ), that if someone wants to call a function, this function is somewhere defined, and the soft_i2c driver didn;t know how this function look like ... and my patch just defines an "API", so that not everybody comes with new names and new includes ... And this include sits no longer in the config file but in the soft_i2c driver ... thats it. I just did this as a fast proposal for what Alessandro suggested: "I don't think my approach is beautiful at all (both #ifndef __ASSEMBLY__ and #include "../board/"), but I didn't find a better solution" see: http://lists.denx.de/pipermail/u-boot/2009-July/056867.html So, I thought, to prevent such includes in a lot of config files, and a lot of new function names for the same thing, it would be nice to have such an "API" ... >> work as they are ... but as we discussed this, this patch is >> not a need, because we can do this functionality also at the >> moment (of course with this unlovley include in the config file) > > What's the difference between include one file or another? I see no > real difference between including <asm/gpio.h> versus <soft_i2c.h>. This is true if we have gpio api! So we just include the gpio.h in soft_i2c.c and it works, but we have not such an API yet ... >> If this is in future a no go (as Jean-Christophe suggested for the >> Kconfig support), we can then maybe switch to this proposal ... > > Well, we should not assume that we can use Kconfig to sole all > configuration issues. This is IMO not possible with reasonable > efforts and within a reasonable time frame. Let's be happy when we > cover 95 or even 90%, and then focus on the rest. But don't lets make > (eventually false) assumptions which constructs may or may not > conflict with a not even yet existing implementation. > > You know - early optimizian has never been a good idea. > >> Hmm... also I don;t want to do this with the "multibus/multiadapter" >> rework, because this rework is for themselve a big change, which >> where I wouldn;t add one more big change ... so we maybe lost control, >> why things no longer work ... > > Heh. Clever, you didn't swallow the bait ;-) :-) 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 [email protected] http://lists.denx.de/mailman/listinfo/u-boot
