Julius Werner wrote:
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.
Not if the architecture is any good.
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.
No - that doesn't make any sense. Probably there will be a fair bit of code that can be shared among controllers. There aren't that many ways to implement I²C.
I think the question is really what we would gain from this.
I think it's less about performance and more about an accurate and clean model being available to mainboard code when needed.
//Peter
2015-02-19 21:12 GMT+01:00 Peter Stuge peter@stuge.se:
I think the question is really what we would gain from this.
I think it's less about performance and more about an accurate and clean model being available to mainboard code when needed. From discussing things with Werner, one of his concerns (as I
understood them) was higher stability in light of picky I2C devices: When you schedule the entire communication in one pass, the (sufficiently capable) controller makes sure that things happen in the right order and at the right time. If some of that is arbitrated by CPU code, there's more room for error.
Even for the I2C controllers that essentially bitbang things with no help by the controller chip, that should help avoid mistakes, since all the nasty warts of I2C (of which were seem to be many) are managed in the bus driver, not in every single slave driver.
Patrick
-
Patrick Georgi -
Peter Stuge