[coreboot] Fwd: Re: New interface for I2C in coreboot

[Alex G.]

I knew there was something wrong to typing that from an Android phone.
It didn't get sent to the list.


-------- Forwarded Message --------

On Feb 10, 2015 2:19 AM, "Patrick Georgi" <> wrote:
> Am 10.02.2015 um 08:56 schrieb Alexandru Gagniuc:
> > That's actually the way I2C is designed to work, and this sort of
API models
> > it more accurately. Linux uses it. libeopencm uses it. spidev uses it.
> But hardware doesn't. The API is fine when you bitbang everything, but
> not when there's a controller that takes over some of the work, like
> programming the address.
>
> On such a controller, you have to pick apart struct i2c_seg* to figure
> out which elements are addresses and which are data, and split things
> into different registers.
>
Is that proper i2c or smbus controllers? Smbus is a different beast that
we really shouldn't simplify to i2c++ .

Assuming it's i2c proper, how do we handle such cases? I2c is i2c and it
makes more sense to abstract the nature of the hardware in an i2c
centric way. A silicon-specific API is the wrong way here.

I have patches in my pipeline to introduce generic i2c over displayport
aux channel code. That makes use of the low level nature of i2c_seg to
properly break down the AUX bus transactions in a hardware-agnostic way.

> I really don't see how it's useful to keep the data structures as low
> level as possible and then require drivers for more capable devices to
> uplift them to a higher abstraction level.
>
See section about abstracting hardware details above. There's no
measurable penalty for internal abstraction. There is however a penalty
for driving the hardware in a suboptimal way. That's the driver's job.

Sure, we can make a context based i2c API based on ops. Then we can
check the direct_read pointer and use that if it's not null. Though most
people will get it wrong when writing drivers. KISS.

Alex