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

[Robert Schwebel]

Hi,

On Wed, Jun 18, 2008 at 01:48:26PM -0500, Menon, Nishanth wrote:
> What issues do you see with the proposed patch set I have send out -
> other than it bases itself on Linux kernel?

I've commented your first patch in the series; in short:

- It shows nicely that it is easy to copy things over from Linux -
  that's a good sign that we didn't do too many things the wrong way. But
  note, it is *not* the main intention of u-boot-v2 to be a Linux clone.
  It is a bootloader, and it tries to be one with a neat design,
  combining the best of POSIX, Linux and U-Boot-v1. Copying *ideas* is
  good, but let's do it in a way that it still is u-boot.

- Please don't bring in things which are not part of the current code
  base. If you add code for subsystems, the subsystems must be there
  first and *then* their users. Otherwhise we bloat the codebase and we
  disable the possibility to add *real* support for PCI, USB and S390
  later :-)

> 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.

No problem with that.

>    iii) does it support multiple buses? Oh yeah it does. So does it
>    support multiples speed busses too.

That's also a requirement.

> b) does it fit in device-driver model? Yep it does.

Sure.

> 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.

See above. Check how Sascha's code for console, serial or clocksource
looks like. It really *looks* like Linux from the outside, but it is
much, much smaller and better aligned for bootloader use.

Back to my proposal:

> > 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.

Which part of i2c do we actually *need* in the bootloader? What's *your*
use case?

I assume we need i2c host controllers, that's quite clear. We also need
an abstraction for i2c devices. The only devices I have seen which
really needed a bootloader driver are

a) eeproms
b) RTCs
c) analog/digital in/outputs (i.e. gpio expanders)

Other use cases?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9