Incorrect pinmux modes reported by sysfs/debugfs?

Anil, thank you for clarifying!

Actually...looking back at Rev C of the datasheet (SPRS647C, Table 4-11, pg 161), I see that bits 18 and 19 are both marked as being Reserved -- you mentioned that 18 is a receiver enable bit?

According to the datasheet, "[bit 18] must always be written as '1'"...but I've been working off of the PSP Userguide which doesn't seem to follow this in the gpio0_0 example.  Mind setting me straight on this?

Thanks!

Hi Jon,

Its depending upon you usage, example might not talk about that.

In case of touch screen that pin is used as a interrupt signal so its configured as receiver enabled.

Look at this definition in kernel source (arch/arm/mach-omap2/mux.h)

#define TI814X_INPUT_EN                 (1 << 18)

You can look at usage at multiple locations on (arch/arm/mach-omap2/devices.c) file.

Regards

AnilKumar

Hi Anil,

I'm now trying to do some prototyping with I2C-dev (linux/Documentation/i2c/dev-interface), and seem to be having some additional problem with the pinmux settings for I2C3 on AH6 and AG6 (i.e., setting dcan0_tx=>i2c3_sda_mux1 and dcan0_rx=>i2c3_scl_mux1).

Here are my bootargs from U-Boot, as obtained by cat'ing /proc/cmdline:

However, the mode settings I've specified do not appear to be taking effect. This is made evident by the fact that I can't "wiggle" the bits via /dev/i2c-4, and the incorrect pinmux register values reported by the following debugfs entries:

Any advice? Thanks!

- Jon

Although it's exactly really relevant here, I've attached my modifications to board-ti814c.c (just to expose i2cdev and spidev interfaces for userspace prototyping).

--- board-ti8148evm.c.bak	2012-05-17 13:37:32.132290224 -0400
+++ board-ti8148evm.c	2012-06-14 11:04:30.838107539 -0400
@@ -120,9 +120,11 @@
 	{
 		I2C_BOARD_INFO("pcf8575_1", 0x21),
 	},
-
 };
 
+/* Empty structure so we can expose I2C-Dev interface */
+static struct i2c_board_info __initdata ti814x_i2c_boardinfo3[] = { };
+
 #define VPS_VC_IO_EXP_RESET_DEV_MASK        (0x0Fu)
 #define VPS_VC_IO_EXP_SEL_VIN0_S1_MASK      (0x04u)
 #define VPS_VC_IO_EXP_THS7368_DISABLE_MASK  (0x10u)
@@ -525,6 +527,8 @@
 				ARRAY_SIZE(ti814x_i2c_boardinfo));
 	omap_register_i2c_bus(3, 100, ti814x_i2c_boardinfo1,
 				ARRAY_SIZE(ti814x_i2c_boardinfo1));
+    omap_register_i2c_bus(4, 100, ti814x_i2c_boardinfo3,
+                ARRAY_SIZE(ti814x_i2c_boardinfo3));
 }
 
 static u8 ti8148_iis_serializer_direction[] = {
@@ -669,6 +673,14 @@
 		.bus_num	= 1,
 		.chip_select	= 0,
 	},
+
+    {
+        .modalias = "spidev",
+        .mode     = SPI_MODE_0,
+        .max_speed_hz = 48000000,
+        .bus_num = 2,
+        .chip_select = 0
+    }
 };
 
 void __init ti8148_spi_init(void)

Forgot to add that I also tried adding omap_mux_init_signal() calls to board-ti8148evm.c instead of using the kernel command lines args:

With this ---^, I had the same results -- bad register values shown by debugfs.

As far as I can tell, I've got these pin strings right... From mux814x.c:

Has anyone had any success with I2C3 pins in their MUX1 configuration (on the DCAN0 pins, AH6 & AG6)?

Anil,

Thank you for the quick reply and detailed response -- I did indeed overlook the TI814X CAN initialization in devices.c.  I am not using the DCAN features at all, so no worries on that.

Also, point taken regarding creating new threads -- I'll be sure to do that from now on.

Again, your time and help are much appreciated - Thank you!

- Jon

Anil said:  "So the functionality is achieved but the flags shown under "mode:" are wrong."

Seems to me like the reason why debugfs reports bad results is this line from omap_mux_decode() in mux.c:

   sprintf(mode, "OMAP_MUX_MODE%d", val & 0x7);

It needs to be something like:

   if (cpu_is_ti814x())
   {
      int tmp_masked_mode = ffs( (val & OMAP_MUX_MODE_MASK) ) - 1;
      if (tmp_masked_mode >= 0 && tmp_masked_mode <= 9)
      {
         sprintf(mode, "OMAP_MUX_MODE%d", tmp_masked_mode);
      }
      else
      {
         strcpy(mode, "OMAP_MUX_MODE?");
      }
   }
   else
      sprintf(mode, "OMAP_MUX_MODE%d", val & 0x7);

Likewise, some of the /sys/kernel/omap_mux/* files will cause a crash because omap_mux_dbg_signal_show() has this line:

        mode = ffs(val) - 1;

Because the ffs(val) might return a bit larger than OMAP_MUX_NR_MODES, m->muxnames[mode] will be invalid.  That line needs to be:

        /* Consider only mode bits to avoid ffs(val) > OMAP_MUX_NR_MODES, causing a crash on m->muxnames[mode] below */
       mode = ffs( (val & OMAP_MUX_MODE_MASK) ) - 1;

And the seq_printf needs to check for -1:

           m->muxnames[0], (unsigned)mode < OMAP_MUX_NR_MODES ? m->muxnames[mode] : none,