[U-Boot-Users] [Patch 0/9] U-boot-V2: Introduce I2C support for SDP3430

[Menon, Nishanth]

Robert,
> -----Original Message-----
> From: Robert Schwebel [mailto:r.schwebel at pengutronix.de]
> Sent: Wednesday, June 18, 2008 1:38 PM
> To: Menon, Nishanth
> Cc: Sascha Hauer; Timur Tabi; Laurent Desnogues; Kamat, Nishant; philip.balister at gmail.com; u-boot-
> users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [Patch 0/9] U-boot-V2: Introduce I2C support for SDP3430
>
> So I suppose the right way to proceed is:
>
> - let's first define use cases for what you want to achieve with the i2c
>   support in u-boot-v2
>
> - let's have a look at how it would integrate into the device/driver
>   model and how the user-visible API would look like
>
> - write a small framework for i2c, with host+algo+device parts, heavily
>   inspired by the best of Linux and the best of u-boot/u-boot-v2.
>
> That worked out very well for the features we currently have in u2.
What issues do you see with the proposed patch set I have send out - other than it bases itself on Linux kernel? It meets the following requirements:
a) does meet all the use cases folks need with i2c:
   i) bare bone i2c arch -> don't use client drivers, just stick around with adapter and use i2c_transfer or smbus ops which ever you'd like.
   ii) someone wants to write a client for a commonly used device ->eeprom or the like.. feel free to do so.
   iii) does it support multiple buses? Oh yeah it does. So does it support multiples speed busses too.
b) does it fit in device-driver model? Yep it does.
c) Is it small? I don't see 6K a big overhead considering similar addition due to devfs or nand support.. in fact my adapter driver could be eating a chunk of that 6K.

Regards,
Nishanth Menon