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
-
Alex G.