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.

Using i2c0_scl as gpio

Other Parts Discussed in Thread: AM3358

We used the am335x evm code as a template for our am3358 board.  We do not use the TI power management IC.  We do not have a need for I2C.  We are trying to use i2c0_scl as a gpio.  It is used to control the reset pin on our ethernet Phy IC.

We have defined this pin for GPIO using uboot and kernel pinmuxing.  We also set the pin high during uboot and kernel board bringup to take the ethernet phy IC out of reset.  In board-am335xevm.c we have removed references to I2C peripherals like the eeprom and power management IC.  

Here is how we set the pin high in the kernel board-am335xevm.c:

#define LA_PHY_RESET    (GPIO_TO_PIN(3,6))
gpio_set_value(LA_PHY_RESET, 1);


When bringing up the system, if we stop at uboot, this pin behaves correctly - the pin is high and it brings the ethernet phy out of reset.  We can use ethernet within uboot. 

If we boot to linux, the pin does not go high.  If I query the system, it reports that the pin is configured correctly:

[root@MT2000 ~]# cat /sys/kernel/debug/omap_mux/i2c0_scl
name: i2c0_scl.gpio3_6 (0x44e1098c/0x98c = 0x0017), b NA, t NA
mode: OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT_PULLUP
signals: i2c0_scl | NA | NA | NA | NA | NA | NA | gpio3_6

I know we have ethernet set up correctly in linux because of the following:  There is a pull-down resistor on the ethernet phy reset line to keep it in reset during early bootup.  If we substitute a very weak pulldown resistor, the voltage level on this reset line does not keep the phy IC in reset.  In that case, when booting to linux ethernet works fine.

It seems that there is something else after the startup in board_am335xevm.c that is inhibiting us driving this pin(?)

Thanks in advance for any insights.

Rod Campbell

  • Can you try:

    gpio_request(GPIO_TO_PIN(3, 6 ), "myethrst");
    gpio_set_value(LA_PHY_RESET, 1);

  • Do you have Smart Reflex disabled? It uses I2C0. You don't need it if you are not using a TI PMIC. This wiki shows how it can be disabled: http://processors.wiki.ti.com/index.php/AM335x_Power_Management_User_Guide#SmartReflex
  • I tried this, but I have the same result.  I noticed in the console bootup some i2c items:

    [    0.906463] i2c-core: driver [tsl2550] using legacy suspend method
    [    0.912963] i2c-core: driver [tsl2550] using legacy resume method

    later:

    [    1.124572] omap_rtc am33xx-rtc: rtc core: registered am33xx-rtc as rtc0
    [    1.131927] i2c /dev entries driver
    [    1.135803] Linux video capture interface: v2.00


    I suppose that this could happen whether or not I have any active I2C devices (we don't).

    Also later in bootup:

    [    1.323028] Power Management for AM33XX family
    [    1.327911] Trying to load am335x-pm-firmware.bin (60 secs timeout)
    [    1.334655] Copied the M3 firmware to UMEM
    [    1.343017] clock: disabling unused clocks to save power

    Not sure about this one.  I don't see anything else related to power management or smart reflex during bootup.

  • Thanks - this was almost exactly what I needed.  I ended up doing:

    #define LA_PHY_RESET    (GPIO_TO_PIN(3,6))

        err = gpio_request(LA_PHY_RESET, "la_ethPhyReset");
        if (err){
            pr_info("MT2000 - could not set eth phy gpio\n");
        } else {
            pr_info("MT2000 - ensure eth phy out of reset\n");
            gpio_direction_output(LA_PHY_RESET, 1);
        }

    I don't know why the following didn't work, it does for some other GPIO in the same file:

    static struct pinmux_config eth_phy_reset_pin_mux_LA[] = {
        {"i2c0_scl.gpio3_6",     OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT_PULLUP},
        {NULL, 0},
    };
        setup_pin_mux(eth_phy_reset_pin_mux_LA);
        gpio_set_value(LA_PHY_RESET, 1);

    But I can't argue with success.  Thanks again!

  • Glad that it worked.  My guess is that the other pin was requested in other code within the kernel. 

    For more GPIO fun: 

    http://processors.wiki.ti.com/index.php/Sitara_GPIO_Driver_User_Guide

    In the PSP's kernel source folder:  linux-3.2.0-psp##.##.##.##/Documentation/gpio.txt