Xilinx iic i2c bus interface GPIO support for i2c-mux in Linux.

We are using a Xilinx FPGA which implements a series of i2c bus interfaces. We are planning on implementing a single-bit GPIO (XIIC_GPO_REG_OFFSET) which is included in that logic block to act as a MUX selector (also in the FPGA) between two separate i2c busses.

This will require a GPIO driver in the linux kernel.

Is it better to try and change the i2c-xiic.c code which already knows about the GPO register to handle that additional GPIO or should we be implementing the GPIO driver outside the i2c driver and then use the standard i2c-mux support available in newer kernels?

Hi Robin,

Quoted 11 lines · Robin Holt

We are using a Xilinx FPGA which implements a series of i2c bus interfaces. We are planning on implementing a single-bit GPIO (XIIC_GPO_REG_OFFSET) which is included in that logic block to act as a MUX selector (also in the FPGA) between two separate i2c busses.

This will require a GPIO driver in the linux kernel.

Is it better to try and change the i2c-xiic.c code which already knows about the GPO register to handle that additional GPIO or should we be implementing the GPIO driver outside the i2c driver and then use the standard i2c-mux support available in newer kernels?

Both are possible. It depends if there are other GPIOs on your FPGA which you will have to access from other drivers for other purposes. If there are such other GPIOs then it certainly makes sense to have a clean, separate gpio driver for your FPGA, and have all consumers bind to it. If not, then I'd keep things simple and embed everything in i2c-xiic.c, especially if the two i2c buses are truly separated and there is no common trunk (i2c-mux would create 3 segments.)

Quoted 15 lines · Jean Delvare

Hi Robin,

Quoted 11 lines · Robin Holt

We are using a Xilinx FPGA which implements a series of i2c bus interfaces. We are planning on implementing a single-bit GPIO (XIIC_GPO_REG_OFFSET) which is included in that logic block to act as a MUX selector (also in the FPGA) between two separate i2c busses.

This will require a GPIO driver in the linux kernel.

Is it better to try and change the i2c-xiic.c code which already knows about the GPO register to handle that additional GPIO or should we be implementing the GPIO driver outside the i2c driver and then use the standard i2c-mux support available in newer kernels?

Quoted 7 lines

Both are possible. It depends if there are other GPIOs on your FPGA which you will have to access from other drivers for other purposes. If there are such other GPIOs then it certainly makes sense to have a clean, separate gpio driver for your FPGA, and have all consumers bind to it. If not, then I'd keep things simple and embed everything in i2c-xiic.c, especially if the two i2c buses are truly separated and there is no common trunk (i2c-mux would create 3 segments.)

Do you know of any other examples of an i2c bus interface which provides a built-in general purpose output for MUX selection? I am hoping for some example of the "right" way to do this.

We are using a Xilinx FPGA which implements a series of i2c bus interfaces. We are planning on implementing a single-bit GPIO (XIIC_GPO_REG_OFFSET) which is included in that logic block to act as a MUX selector (also in the FPGA) between two separate i2c busses.

This will require a GPIO driver in the linux kernel.

Is it better to try and change the i2c-xiic.c code which already knows about the GPO register to handle that additional GPIO or should we be implementing the GPIO driver outside the i2c driver and then use the standard i2c-mux support available in newer kernels?

Any guidance is welcome.

Thanks,
Robin Holt
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html