• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 752 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Kernel overwrites uboot's pinmux setup, am389x/dm816x

argeebee
Intellectual 835 points

It appears that the kernel is overwriting our uboot's pinmux setup.  For example, uboot sets up GPMC_DIR to mode 1, so that it functions as GPIO Bank 1, pin 20.  The pin is set high and is verfied on the scope. 

When the kernel boots, the pin goes low which indicates that the pin value was overwritten.  I've tried commenting out the init for board_mux[] in board-ti8168evm.c.  This resulted  in the kernel not being aware of any pins in the board_mux[] array, so the /debugfs/omap_mux showed no pin configurations. 

Next, I tried using a combination of omap_mux_init_signal() and gpio functions as listed in gpio.h. I used gpio_set_value() to set GPIO Bank 1, pin 20 to 1.  However, the scope showed that the pin was still low.  Are there other places that reconfigure or reset the pinmux?

Our kernel is based on DM81xx/AM38xx PSP 04.00.02.14, 2.6.37.   Thanks in advance.

  • 0
    TI__Guru**** 161600 points

    Hi,

    Could you please post this question to DM816x, C6A816x and AM389x Processors Forum (http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717.aspx)? I am not familiar neither with the devices architecture, nor with the PSP they use.

    This forum (Sitara Processors Forum) supports only AM335x and AM437x devices, and their linux based EZSDK.

    Best Regards,

    Yordan

  • 0 in reply to Yordan Kovachev
    TI__Guru**** 393215 points

    Moving this to the correct forum.

  • 0
    TI__Guru**** 170625 points

    Argeebee,

    argeebee said:
    Our kernel is based on DM81xx/AM38xx PSP 04.00.02.14, 2.6.37.

    First of all, you are using very old version of the PSP. Please switch to the latest DM816x/TI816x/TI81xx linux kernel:

    - in case of EZSDK:

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

    - in case of DVR RDK:

    http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git;a=shortlog;h=refs/heads/dvrrdk_kernel_int_branch

    Please try with the latest linux kernel (which is PSP04.04.00.02 plus some patches in addition) and see if you will have the same error.

    Regarding pin mux in kernel, please make sure you are aligned with the below wiki page:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_User_Guide#TI816X_3

    See also if the below e2e threads will be in help:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/191218/715341.aspx#715341

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/343911.aspx

    BR
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 835 points

    Thank you for the suggestions.  I haven't  tried the newer kernels, since I think I'm close to a possible solution with the kernel that we have.   So far, I've observed the following behavior:

    - uboot sets GPMC_DIR as GPIO 1, pin 20 as output, set hi

    - verified with scope that pin is hi.  This is the desired state

    - kernel seems to set as input, scope shows pin is low, so added code at the end of ti8168_evm_init() to set it as GPIO, output, set hi

    - scope shows that pin goes low for 200 ms, then goes hi and stays hi


    I want to avoid the low state, so I moved the GPIO setup code at the top of ti8168_evm_init(), however the scope still shows that the pin is low for 200 ms.  I want to avoid the low state because this pin is going to be routed to the power supply to reset our device.  If the pin is low too long, the power supply will shut off.

    To explain the 200 ms delay in GPIO activity, it seems to me that there is something that disables/inhibits the GPIO block, so that my register writes don't take effect until the GPIO block is active.  If this is the case, if I can activate the GPIO block earlier, then I can avoid this 200 ms low time.

    Informational for programmers using the gpio_request(), etc, API:  after gpio_free() is called, the GPIO seems to revert to input, so if a pin is configured to output, set hi, gpio_free() appears to undo the setting.  On the scope, after setting the direction and value, the pin is high.  After the call to gpio_free(), the voltage on the pin starts to decay slowly and becomes low.  To avoid losing the setting, I don't call gpio_free().

  • 0 in reply to argeebee
    TI__Guru**** 170625 points
    Argeebe,

    See also if the below links will be in help:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_GPIO_Driver_User_Guide#Kernel_Level

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/386406/1365233#1365233

    BR
    Pavel
  • 0
    Intellectual 835 points

    Thanks for the tips!  I traced it to code that does resets to a module.  To prevent it, I check if the module is GPIO, if so, I don't do the reset. 

    WARNING:  only prevent the reset if you are really, really sure that u-boot set the pin mux properly. 

    arch/arm/mach-omap2/omap_hwmod.c

    As an extra measure, in gpio_output_array() I also don't clear the pin value

    arch/arm/plat-omap/gpio.c