We have a custom board, with peripherals connected to I2C3. I noticed these lines in board-support/linux-2.6.37-psp04.04.00.01/arch/arm/mach-omap2/i2c.c:
void __init omap2_i2c_mux_pins(int bus_id)
{
char mux_name[100];
/* First I2C bus is not muxable */
if (bus_id == 1)
return;
if (cpu_is_ti814x() && bus_id == 3) {
sprintf(mux_name, "uart0_dcdn.i2c2_scl_mux0");
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
sprintf(mux_name, "uart0_dsrn.i2c2_sda_mux0");
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
} else {
sprintf(mux_name, "i2c%i_scl.i2c%i_scl", bus_id, bus_id);
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
sprintf(mux_name, "i2c%i_sda.i2c%i_sda", bus_id, bus_id);
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
}
}
In fact, this setting conflicts with my need for uart0_dcdn.gpio1_2 and uart0_dsrn.gpio1_3.
I use the output of the pinmux utility to set up all pinmux settings in u-boot with "MUX_EVM()", so I tried commenting the above lines out. But when I do that, the debugfs report for i2c3 seems contradictory:
# cat /sys/kernel/debug/omap_mux/dcan0_*
name: dcan0_rx.i2c3_scl_mux1 (0x48140910/0x910 = 0x60020), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: dcan0_rx | uart2_rxd_mux2 | NA | NA | NA | i2c3_scl_mux1 | NA | gpio1_1
name: dcan0_tx.i2c3_sda_mux1 (0x4814090c/0x90c = 0x60020), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: dcan0_tx | uart2_txd_mux2 | NA | NA | NA | i2c3_sda_mux1 | NA | gpio1_0
I.e. it has the correct name ("dcan0_tx.i2c3_sda_mux1"), but still says MODE0 instead of MODE7.
When I try to access bus 3, I get "omap_i2c omap_i2c.3: controller timed out" ...
So I ask: Why would a call to set up bus 3 be forced to set up i2c2?
Dan -