logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.

Can't set input voltage on GPIO

posted in Linux Kernel
Friday, December 12 2014, 03:00 PM
tlwest
tlwest
Offline
0
We have a GPS sending a pulse every second to GPIO 140, which has the MUX set and is input-enabled.

With the stock kernel it works. The OMAP detects it, and an oscilloscope attached to the J990 pin sees the pulse. With the debug kernel we can see the MUX for MCBSP3_DX set to mode 4 (GPIO 140) and input enabled.

We make some modifications to the kernel to add a device driver and reboot.

With the debug kernel, we can the the identical MUX status, however, the oscilloscope attached to the J990 pin does not see a pulse. Something is pulling the voltage low.

Question: What other factors outside of the MUX could be responsible for pulling the pin low?

I suspect, but haven't confirmed, that this is also responsible for the problem I had reading from the UART in a previous post.

Many thanks.
Responses (3)
  • Accepted Answer

    Monday, December 15 2014, 11:00 AM - #permalink
    0
    Hi tlwest,

    Question: What other factors outside of the MUX could be responsible for pulling the pin low?

    GPIO 140 is shared with TWL4030 PCM VSP module. By default, stock kernel disables PCM VSP. So I suspect that your modifications enable PCM VSP and pull low your GPIO pin.

    When you set MCBSP3_DX (GPIO140) as mode 7 (high impedance), do you have the same behavior?

    More information at:

    https://isee.biz/support/disable-pcm-vsp-on-tps65950-to-use-mcbsp3
    http://labs.isee.biz/index.php/Connectors_Summary

    Cheers!
    The reply is currently minimized Show
  • Accepted Answer

    tlwest
    tlwest
    Offline
    Monday, December 15 2014, 07:09 PM - #permalink
    0
    Many thanks for your suggestion.

    I set pin 4 (mcbsp3_dx) to mode 7 and mode 107 (input enabled) just in case.

    In both cases, pin 4 remains flat with my kernel and show 1 second pulse with stock kernel (2.6.37-6).

    I will investigate the VSP module, although I don't see any signs of it in dmesg output.
    The reply is currently minimized Show
  • Accepted Answer

    tlwest
    tlwest
    Offline
    Monday, December 15 2014, 11:28 PM - #permalink
    0
    Indeed, it appears your diagnosis was correct, and, as I suspected, also answers the problem I had with the UART.

    If you do not instantiate the "sound card" in igep0020.c,

    ret = platform_device_add(igep2_snd_device);


    then the call path of

            twl4030_soc_probe -> twl4030_init_chip -> twl4030_reset_registers
    (all found in sound/soc/codecs/twl4030.c)

    never gets called and the TPS65950 never gets turned off. (The values intended for the registers (twl4030_reg) are set appropriately as

    	0x04, /* REG_VOICE_IF		(0xF)	*/


    but the values are never actually written to the register.)

    With the TPS65950 active, pins 4, 6 and 8 are pulled down, preventing GPIO 140 and UART2 from functioning.

    Many thanks for the pointer.
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat