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
accurately. Linux uses it. libeopencm uses it. spidev uses it.
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.