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.

Linux: GPIO question

Other Parts Discussed in Thread: DRA726

Tool/software: Linux

I had issues creating a new thread, apparently DRA726 is no longer a valid part number according to this site.

I have a small issue with a GPIO and would need some help on this. We have a co-processor which looks at a GPIO and if it is off will turn the power on if the line has gone from high to low and the ignition is turned on. On power up it ignores the status of the ignition and turns on the power for the PMIC either way. When Linux shuts down the GPIO should normally go down. I have a pulldown on the GPIO. On some boards the GPIO stays high until we touch the line with a probe (scope or multimeter).

I use a LED setting for the GPIO, is there a way to have a GPIO entry in the devicetree without using the LED mode? I would like to change my power down with first bringing the line down and the issuing a shutdown. The co-processor can have a small delay to allow me to do a clean shutdown. Once it sees the line goes down it brings the control line low and then tri-state before going to stop mode. Doing so before the linux shutdown would keep from having a clean shutdown.

I am hoping that bringing that line down before the shutdown would fix things up. I won't know until I try it out but with the GPIO as a LED I can't access it as a GPIO.

Is there a reason why the default state of the LED is only done after the kernel is all loaded? anyway to turn the GPIO on early on? The programmer of the co-processor tells me that it takes about 10 seconds before he can see the line going high.

Michel Catudal

ACTIA Corp

  • Hi Michel,

    I have forwarded your question to GPIO expert.

    Regards,
    Yordan
  • Hi Mike,

    You do not have to have a LED device as such.
    You can use Linux sysfs to control GPIOs from userspace.
    Refer www.kernel.org/.../sysfs.txt

    Regards,
    Nikhil D
  • Nikhil,

    I get the same results either way. It takes around 10 seconds before the correct value is set. The Application takes around 30 seconds before it would set the port so it would be too late using the GPIO. I was looking for a way to get the GPIO setup correctly as Linux boot and not 10 seconds later.

    I fixed the problem with this :

    &gpio2 {
    ti,no-idle;
    ti,no-idle-on-init;
    ti,no-reset-on-init;
    };

    I was concerned that it may affect other GPIO bits on that port. Most of the GPIO on that port are used by the TI-RTOS code in the M4. I need to double check the ones that are used on Linux to make sure they are accessible.

    I force the HEALTH GPIO as ON for the co-processor in u-boot. If that line is not set the co-processor would turn the power off the PMIC thus bricking the board until I erase the code in the co-processor using J-TAG. When I do a shutdown with Linux the line goes low and the co-processor goes to stop mode after it turns the supply of the DRA726 off.

    Michel Catudal
    ACTIA Corp
  • Hi Mike, Ideally, it is not recommended to use few GPIO lines from Linux and few from BIOS We do not want multiple drivers controlling the same IP. In case you have already designed your board where you NEED to share GPIO IP between Linux and BIOS You have added the correct properties in the DTS. This makes sure that Linux will not reset / idle the GPIO. Now, if you want Linux to setup some GPIO lines as soon as the driver is loaded, you can use the gpio-hog node. It will set the line high/low as soon as the gpio driver is loaded. but, note that you wont be able to change the gpio from any other driver, userspace if you use hog. If you want to be able to change it later but still want to update ASAP, you should use lines-initial-state property of the GPIO node Set the corresponding bit in active_low polarity Regards, Nikhil D