[RFC linux dev-4.7 0/4] drivers: i2c: FSI-attached I2C master algorithm

[Brad Bishop]

[snip]

>> 
>>> The driver will currently set up one chardev for each master (each proc).
>>> The port is then specified by hacking the addr field of i2c_msg. It works,
>>> but not a clean solution.
>> I’d say we just go with one chardev per port, unless others have experience
>> that recommends otherwise.
> 
> Thought of a potential issue with this approach. This will require some custom bus locking solution, as we need to prevent multiple transfers from setting the master regs at the same time.

Does each port have its own reg(s) or do bits n-m in reg x correlate to ports n-m?

> Obviously the kernel i2c driver handles locking on each chardev to prevent simultaneous access, but since we will have multiple chardevs that have to lock each other out, we need to do it ourselves.
> 
> I think having our own locking is pretty do-able, I just wonder if the kernel guys will not be happy with it?
> 
> Eddie
>> 
>>> FSI clocking details are not defined in the device tree, so FSI clock is
>>> hardcoded for now.
>>> 
>>> Edward A. James (4):
>>>  drivers: fsi: Add function to get FSI clock rate
>>>  drivers: i2c: Add FSI-attached I2C master algorithm
>>>  drivers: i2c: Add transfer implementation for FSI algorithm
>>>  drivers: i2c: Add bus recovery for FSI algorithm
>>> 
>>> drivers/Makefile             |   2 +-
>>> drivers/fsi/fsi-core.c       |   7 +
>>> drivers/i2c/busses/Kconfig   |  11 +
>>> drivers/i2c/busses/Makefile  |   1 +
>>> drivers/i2c/busses/i2c-fsi.c | 608 +++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/fsi.h          |   1 +
>>> 6 files changed, 629 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/i2c/busses/i2c-fsi.c
>>> 
>>> -- 
>>> 1.8.3.1