On Thu, Feb 19, 2015 at 12:21 AM, Werner Zeh <werner.zeh(a)gmx.net> wrote:
OK, forget my last Mail...I was to blind to see the
We already have my approach with the new interface.
We maybe can expand it to have informations like time-out or retry count for a given
One word of caution I'd like to add here is that making this API more
complex/powerful requires significant effort, now and in the future.
We already have 4 I2C driver implementations in coreboot, and 4 more
are going to be upstreamed soon from the Chromium tree. As we scale up
to we'll probably add at least one new driver per SoC vendor, maybe
even per SoC. Adding complex functionality like retries to the API
will require us to account for it over an over again in every single
I think the question is really what we would gain from this. Even
though some I2C controllers have more efficient modes that do multiple
things at once, all I've yet seen could somehow be coerced to do real
simple step-by-step transfers. Since we need to implement that anyway
for the API, why do anything more? Efficiency? I think I2C transfers
are generally so slow that a little more overhead here and there isn't
going to make a measurable difference. These transaction-at-a-time
hardware features are designed for operating systems that have other
threads to schedule or the power impact of a high interrupt frequency
to worry about, not us.