• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 667 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAP4460 gpio 176

Joe Shidle
Intellectual 440 points

We have an OMAP4460 ES1.1 processor on custom board.  We're using the 4AI_1.4-P1 Android BSP using the blaze tablet configuration with modifications specific to our hardware, including a number of GPIOs.  We've had no problems with the other GPIOs we've been using, but GPIO 176 (KPD_ROW4 signal name) seems to be causing us trouble.  Regardless of its data value, it is always low at 0V.  We initialize it the way we've initialized all the other GPIOs:

gpio_request(176, "gpio_176");

gpio_direction_output(176, 1);

We've also (for sanity) depopulated the silicon on the other end of GPIO 176 so that electrically it's isolated and it remains low.  I have tried using /sys/class/gpio/export to create a /sys/class/gpio/gpio176:

echo 176 > /sys/class/gpio/export

echo out > /sys/class/gpio176/direction

echo 1 > /sys/class/gpio176/value

GPIO 176 remains low.

At this point, we're afraid the PCBA is fouled (shorted or otherwise) but wanted to ask if there was something unique about GPIO 176 that's not readily apparent. 

Thanks in advance,

Joe Shidle

joe.shidle@deltamobile.com

  • 0
    TI__Expert 3245 points

    Hi Joe,

    Can you check the configuration of the register CONTROL_CORE_PAD0_KPD_ROW3_PAD1_KPD_ROW4 (physical address 0x4A100188)?

    Bits 18-16 control the mux mode for the ball J25 which gpio_176 is mapped to. These bits should have the value 0x3 to mux gpio_176 to ball J25.

    Cheers
    Jon

  • 0 in reply to Jon Hunter
    Intellectual 440 points

    Thanks for the response, Jon.

    That's the peculiar thing.  Reading the physical address 0x4A100188 yields 0x000F000F which is 0x7 = safe mode for the KPD_ROW4 pin.  Forcing it to 0x000B000F via omapconf correctly gets the pin into GPIO mode and I can control that line via /sys/class/gpio now.  So that's a relief that the ball isn't shorted.

    But then I'm wondering why the gpio_request() etc. sequence isn't setting the muxing as requested?  I'd also tried omap_mux_init_signal() which hadn't worked for me.  What might I be missing in board initialization to mux this pin?

    Thanks in advance,

    Joe Shidle

  • 0 in reply to Joe Shidle
    TI__Expert 3245 points

    Joe Shidle said:

    That's the peculiar thing.  Reading the physical address 0x4A100188 yields 0x000F000F which is 0x7 = safe mode for the KPD_ROW4 pin.  Forcing it to 0x000B000F via omapconf correctly gets the pin into GPIO mode and I can control that line via /sys/class/gpio now.  So that's a relief that the ball isn't shorted.

    Great!

    Joe Shidle said:

    But then I'm wondering why the gpio_request() etc. sequence isn't setting the muxing as requested?  I'd also tried omap_mux_init_signal() which hadn't worked for me.  What might I be missing in board initialization to mux this pin?

    Yes gpio_request() will not set the mux. What did you pass to omap_mux_init_signal()? You could try using omap_mux_init_gpio() instead.

    Cheers
    Jon

  • 0 in reply to Joe Shidle
    TI__Expert 8055 points

    Joe,

    Also, how do you have the pin muxing set for this pin in the x-loader and other places in the kernel?

    For example, in the  x-loader for Blaze Tablet, we have:

    MV(CP(UNIPRO_RX0) , ( PTD | M7)) /* unipro_rx0 */ \
    MV(CP(UNIPRO_RY0) , ( PTD | M7)) /* unipro_ry0 */ \

    I realize it is confusing due to the unipro naming.  From x-loader/include/asm/arch/mux.h:

    #define CONTROL_PADCONF_UNIPRO_RX0 0x0188
    #define CONTROL_PADCONF_UNIPRO_RY0 0x018A

    This maps to the register 0x4A100188 that you read.

    You are setting the direction / pull type, through the gpio_request() sequence, but you aren't actually setting this pin to mux mode 3 for GPIO.

    Regards,
    Gina 

  • 0 in reply to Gina Glaser
    Intellectual 440 points

    Thanks folks, I think this is enough to go on.  I had tried:

    omap_mux_init_signal("kpd_row4.gpio_176", OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);

    .. and some other variations on the mux options sent, with no luck but omap_mux_init_gpio(176, OMAP_PIN_OUTPUT) seems to work as expected.

    Also, the x-loader info is a great help too and I was thrown off by the unipro originally.

    Thanks!