On Thu, Feb 19, 2015 at 12:21 AM, Werner Zeh werner.zeh@gmx.net wrote:
OK, forget my last Mail...I was to blind to see the truth :-) 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 segment.
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 implementation.
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.
-
Julius Werner