> The problem is that since all I2C device drivers are written in the way
> above, I am having trouble writting the code for this I2C bus. The
> master_xfer function accepts a list of i2c_msg. So for a I2c read my
> driver would get 2 messages one with the first byte (address write) and
> one with the read buffer, although this is a single I2C transaction!
>
> How can I glue the I2C code to this interface?
> Is there a bus similar to the MPC82xx implemented already?
>
> Can I assume that the i2c_msg list passed to the master_xfer function
> will always contain a single I2C transaction? This way I could setup the
> buffers using the i2c_mgs elements and when the list finishes, I cound
> issue the "I2C start" command.
You can parse the msg list for validity and if it contains anything you
don't grok, reject it. That's a bit of a pain though. That's why for
PowerMac (see the patches that just went in rewriting the PowerMac i2c
code), I have my own low level layer that uses different semantics
closer to what Apple HW provides and one stub driver that hooks to linux
i2c layer. In that stub, I chose to mostly implement the "smbus"
transactions. In fact, smbus transactions map to pretty much 90% of the
needs of most i2c devices around here. Of course, that mean you can't
use existing i2c drivers that use the master_xfer() entry and not the
smbus API, but then, do you really want to use an existing i2c driver ?
I find them generally of no use as they don't know anything about the
specifics of the platform anyway.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
