This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM814x I2C3 pinmux setup

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 -

  • Hi,

    You need to update pin-mux map done in u-boot in Linux kernel as well. Pin-mux settings gets overwritten in Linux kernel as well.

  • Hardik,

    I assume that "MUX_EVM()" from pinmux utility used in u-boot will set up all pinmuxes.  If so, then isn't it best to comment out all pinmux settings in kernel?

    Dan -

  • Hi,

    Only minimum required pin settings are done in u-boot, while rest of the settings are done in kernel, and some of the device drivers like I2C do pin settings based on requirement. So removing pin mux settings is not an option.

  • Hardik,

    Maybe my setup is not clear.  I'm using the "MUX_EVM()" macro generated by the TI Pin Mux Utility, version 2.02.00.00.  It generates writes for PINCNTL1 to PINCNTL270 (except for PINCNTL66-67 and PINCNTL265-269).  Is that not all pin settings?

    Dan -

  • Hardik,

    I found it.  The HPDET pinmux is being overwritten in drivers/video/ti81xx/ti81xxhdmi/hdmi.c, in ti814x_enable_ddc_pinmux():

    temp = 0xe0002;
    __raw_writel(temp, (base+0x0934));
    temp = 0xe0002;
    __raw_writel(temp, (base+0x0938));
    temp = 0x60010;
    __raw_writel(temp, (base+0x09b8));
    temp = 0x40010;
    __raw_writel(temp, (base+0x09bc));

    They were elusive because these functions circumvent the omap_mux functions.  When I disable these, then my u-boot settings are conserved.

    Anyway, I'm still interested to hear if you still believe that the "MUX_EVM()" macro generated by the TI Pin Mux Utility, version 2.02.00.00 is insufficient.  (Previous post.)

    Thanks,

    Dan -

  • Apologies ... I've conflated two separate pinmux problems ... I shouldn't have posted the HPDET thing here.