Yes Patrick, you get me right.
Why should we spread the work that can be commonly done by the I2C
controller driver
over several slave drivers.
I was concerned of several issues on the I2C bus due to the following
policy:
I2C is a slow, low bandwidth bus, let us do the single transfers byte
wise in the background task.
This has two disadvantages:
1. If you have a serious bug and you have to look at the physical bus
level to get a clue what is going on there,
you have to capture a lot of time with an oscilloscope and your single
transfers will be interrupted by huge gaps
(because the transfers are spitted and other things happens in between).
This makes it really hard to analyze.
2. There is a bigger chance to mess up the slave. If that is happen, you
can get a hanging I2C bus. And in the worst case
you will have to power-cycle your slave (and in the most cases your
board as well) to get the slave in the working condition again.
In my point of view, it is much better to keep transfers on I2C bus as
close as possible together to avoid errors.
Werner
Am 20.02.2015 um 17:30 schrieb Patrick Georgi via coreboot:
2015-02-19 21:12 GMT+01:00 Peter Stuge <[email protected]>:
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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
