GPIO pins on DVDD_M seem to not work properly

I did not see that section.  I will take a look.  Where can I get the very latest TRM?  

Thanks,

Craig

Craig,

The latest Technical Reference Manual (TRM Rev. C) is in our TI product folder:  http://www.ti.com/product/tms320dm8148.

BR,

Viet

I had a slightly older TRM that did not have that section.  I thought I had gone through the TRM.  It looks like the latest TRM has this new section.

Thanks,

Craig

What makes things confusing is the MLPB reference in the TRM vs the datasheet.  The Pin Mux table in the datasheet for those pins shows these pins muxible as gpio's.  No other setup.  However there must have been an older datasheet that allowed these pins to be muxible for the MLBP_XXXX.

Craig

Hi,

I am trying to read values from W1, W2, V1 and V2 balls configured as an inputs. I think I have done everything I should, but it does not work under /sys/class/gpio API. My procedure looks:

u-boot:

    /* Enable receivers on balls W1, W2, V1, V2 */
    __raw_writel(0x3F, 0x48140E18);
    __raw_writel(0x3F, 0x48140E1C);

Soon after, configuring PINCTRL 62-65 to 0x000D0080.

In Linux:

echo 39 > /sys/class/gpio/export
echo 40 > /sys/class/gpio/export
echo 41 > /sys/class/gpio/export
echo 42 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio39/direction
echo in > /sys/class/gpio/gpio40/direction
echo in > /sys/class/gpio/gpio41/direction
echo in > /sys/class/gpio/gpio42/direction
cat /sys/class/gpio/gpio39/value
cat /sys/class/gpio/gpio40/value
cat /sys/class/gpio/gpio41/value
cat /sys/class/gpio/gpio42/value

Values read are always 0, no matter what voltage I apply to the pin. Any ideas why it may not work? I checked other pin muxes and set them properly not to overlap GP1 setting.

Greg

Hi,

      Have you seen the  link http://processors.wiki.ti.com/index.php/TI81XX_PSP_GPIO_Driver_User_Guide . There can be multiple reasons for this. Even if you do a settings in u-boot level, kernel is doing next level of pin-muxing so that chances are there that it is over-written. Kindly read the registers again from linux to make sure that kernel didn't altered the settings. Other possibility is that some drivers may be accessing the pins. Kindly do the procedures in the guide to check whether the pin is already acquired by any of the drivers.

Regards

Faizel 

We patched our kernel to support those GPIO.  You need to see the TRM for the 8148 as it address this situation.

Here is a basic patch I created.  You should be able to modify this as you need.

# HG changeset patch
# User Craig Matsuura <cmatsuura@2gig.com>
# Date 1360110952 25200
# Tue Feb 05 17:35:52 2013 -0700
# Node ID 9af91474f913fa34f1247e06f29d6071afd88fac
# Parent cd2dc88a45e5b7d4d7c552453e3362b319d5ac9b
Added special handling for GP1[7:10] because they are on the MLBP pins. See TRM.

diff -r cd2dc88a45e5 -r 9af91474f913 linux-2.6.37/arch/arm/mach-omap2/mux.c
--- a/linux-2.6.37/arch/arm/mach-omap2/mux.c Mon Jan 28 08:55:15 2013 -0700
+++ b/linux-2.6.37/arch/arm/mach-omap2/mux.c Tue Feb 05 17:35:52 2013 -0700
@@ -102,6 +102,37 @@

static char *omap_mux_options;

+/*
+* For now we handle gpio1[7-10] special and will setup them up as outputs.
+* I/O control should be handled in the plat-omap/gpio.c when the direction is
+* setup. We could move this code to the gpio.c when the gpio is requested.
+*
+* For now it will be here defaulting to an OUTPUT.
+*/
+static void __init __special_handling_gpios(u16 reg_offset)
+{
+#if defined(CONFIG_ARCH_TI814X)
+ switch (reg_offset) {
+ case TI814X_CONTROL_PADCONF_MLBP_SIG_P_OFFSET: /* Setup for gpio1_7_mux1 */
+ printk("mlbp gpio1_7 setup\n");
+ omap_writel(0x34, 0x48140E18); /* As output */
+ break;
+ case TI814X_CONTROL_PADCONF_MLBP_SIG_N_OFFSET: /* Setup for gpio1_8_mux1 */
+ printk("mlbp gpio1_8 setup\n");
+ omap_writel(0x34, 0x48140E18); /* As output */
+ break;
+ case TI814X_CONTROL_PADCONF_MLBP_DAT_P_OFFSET: /* Setup for gpio1_9_mux1 */
+ printk("mlbp gpio1_9 setup\n");
+ omap_writel(0x34, 0x48140E1c); /* As output */
+ break;
+ case TI814X_CONTROL_PADCONF_MLBP_DAT_N_OFFSET: /* Setup for gpio1_10_mux1 */
+ printk("mlbp gpio1_10 setup\n");
+ omap_writel(0x34, 0x48140E1c); /* As output */
+ break;
+ }
+#endif
+}
+
static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
int gpio, int val)
{
@@ -142,9 +173,11 @@
if (gpio_mux->reg_offset == TI814X_CONTROL_PADCONF_USB_DRVVBUS_OFFSET) {
mux_mode |= (1 << OMAP_MUX_MODE1);
}
- else
+ else {
/* All other GPIO are MODE7*/
mux_mode |= (1 << OMAP_MUX_MODE7);
+ __special_handling_gpios(gpio_mux->reg_offset);
+ }
#else
mux_mode = val & ~(OMAP_MUX_NR_MODES - 1);

@@ -277,6 +310,8 @@
else
pr_debug("GPIO assigned to %s GP%d_%d (%d)\n",muxname,bank,gpio,(bank*32)+gpio);
mux->gpio = (bank*32) + gpio;
+
+ __special_handling_gpios(mux->reg_offset);
}
else
{

Hi,

     Kindly verify the code by reading back the register settings from linux. You can use any of the memory read write utility.

Regards

Faizel

Hi,

I double checked everything. Here are register settings from Linux level. All seem to be set properly.

root@am3874:~# devmem2 0x481408F4 w
/dev/mem opened.
Memory mapped at address 0x400fb000.
Read at address  0x481408F4 (0x400fb8f4): 0x000D0080
root@am3874:~# devmem2 0x481408F8 w
/dev/mem opened.
Memory mapped at address 0x40064000.
Read at address  0x481408F8 (0x400648f8): 0x000D0080
root@am3874:~# devmem2 0x481408FC w
/dev/mem opened.
Memory mapped at address 0x40272000.
Read at address  0x481408FC (0x402728fc): 0x000D0080
root@am3874:~# devmem2 0x48140900 w
/dev/mem opened.
Memory mapped at address 0x400b2000.
Read at address  0x48140900 (0x400b2900): 0x000D0080
root@am3874:~# devmem2 0x48140E18 w
/dev/mem opened.
Memory mapped at address 0x40218000.
Read at address  0x48140E18 (0x40218e18): 0x0000003F
root@am3874:~# devmem2 0x48140E1C w
/dev/mem opened.
Memory mapped at address 0x40162000.
Read at address  0x48140E1C (0x40162e1c): 0x0000003F

I will try patch for kernel code, but I doubt it helps, since it does not change anything in current config. For suggestion that these pins can be used by other interfaces, I think it is missed, because according to manual, they cannot be assigned to anything else apart from GPIO1. Beside, PINMUX settings show GP1 selections. What else could be wrong? Did anyone try similar setup?

Hi,

      I don't have experience in 8148 platform. For our case (8107), 1. pinmux setting 2. In/Out setting 3. Pullup/Pulldown setting from the kernel made it work.

Regards

Faizel