[RFC linux dev-4.7 0/4] drivers: i2c: FSI-attached I2C master algorithm
Eddie James
eajames at linux.vnet.ibm.com
Thu Mar 16 08:44:45 AEDT 2017
On 03/10/2017 08:16 PM, Brad Bishop wrote:
>> On Mar 10, 2017, at 4:48 PM, Eddie James <eajames at linux.vnet.ibm.com> wrote:
>>
>> From: "Edward A. James" <eajames at us.ibm.com>
>>
>> This patch series adds an I2C bus algorithm to drive the I2C master located on
>> POWER CPUs. The master is accessed over FSI bus from the service processor.
>>
>> The driver is functional for some basic read/write ops. There are a couple of
>> details regarding the device tree and chardev entries that need working out.
>>
>> Mainly, do we want a char device for each port? There are 15 ports off one P9
>> master, so that'll be a lot of /dev/i2c-<x> entries.
> IMHO I don’t see this being a problem.
>
>> One issue is that
>> i2c_add_adapter always names it's device i2c-%d, regardless of adapter name.
> One can always add udev rules to get alternate naming schemes.
>
>> Furthermore, you can specify the number to label it with
>> i2c_add_numbered_adapter, but how to prevent collisions with regular i2c
>> devices?
> I think this is also probably solvable with udev.
>
>> 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. 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
More information about the openbmc
mailing list