[U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> In message <4A6EF6E4.2060407 at denx.de> 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