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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot