LEDs on OMAPL138

Hello,

ARM needs to be in previliged mode to modify PINMUX registers, so it cannot be done from userspace.

Thanks,

Sekhar

So How can i set  PINMUX ?

Once its done Then can i access GPIO through devmem2 ,?

What will be address ?

Thanks

Hello,

PINMUX needs to be setup from kernel only.

You can see CONFIG_GPIO_SYSFS for interface to access GPIOs from user space.

Thanks,

Sekhar

Thanks Sekhar,

Ok So if i configure PINMUX using sysfs then i should be able to use Devmem2 for GPIO .

I know there is alternative using following steps 

echo $PORT > /sys/class/gpio/export        Open a GPIO port for writing

echo $PORT > /sys/class/gpio/unexport        Release the GPIO port

echo "high" > /sys/class/gpio$PORT/direction Take the port high

echo "low" > /sys/class/gpio$PORT/direction Take the port low

But want to use devmem2,so i need absolute address right?

And again my previous question where i could find this info.

Thanks

Alok

Thanks Sekhar that was helpful .

PINMUX in kernel then Devmem2 for GPIO worked for me.

But still PINMUX in kernel is combersome task and a static solution,

Cant i make kernel module that can change PINMUX Configuration on fly.

Alok

Alok,

Typically pinmux once setup does not have to change during the runtime of the system. Can you let me know some details of the usecase and why the pins used in the system need to change dynamically?

You are right, a kernel module can be used to change pinmux configuration, but I wonder regarding the usecase here.

Thanks,

Sekhar

Sekhar Nori said:

You will find information on the register addresses in the Processor datasheet.

actually you won't - it's in spruh77a.pdf table 21.1

but I'm still confused.  I'm pretty sure I have my pinmuxes set up (I set them in UBL and turn on an LED to make sure and it stays lit even at boot prompt so it makes it thru u-boot and kernel boot) and disabled pinmuxing in the kernel.  Also enabled spidev in the kernel of course.

for example in the table we have

so which number should I use?

Looking at http://omappedia.org/wiki/GPIO#FAQ I came up with:

echo 97 > /sys/class/gpio/export

echo out > /sys/class/gpio/gpio97/direction

cat /sys/class/gpio/gpio97/value 

1

echo 0 > /sys/class/gpio/gpio97/value

cat /sys/class/gpio/gpio97/value 

1

for some reason it's stuck as one (and the LED which lights when it's 1 also stays lit).

Is 97 the right number?

Should I be using the gpiochip* register(s) - whatever they are?

ls /sys/class/gpio 

export gpiochip0 gpiochip32 gpiochip96 gpio97 gpiochip128 gpiochip64 unexport

also is there an explanation of the available nodes once you export a pin?  e.g.:

ls /sys/class/gpio/gpio97

active_low direction edge subsystem uevent value

confused!

Hi Bowerymarc,

Note: Always its better to make a different post which better than posting in a "Answered question"

1. Pinmux should be configured for GPIO97, if its changed in the kernel then we cannot control the GPIO from user space.

2. Run these commands for knowing what are the GPIO's already requested in the drivers, which can not controlled from user space.

$ mount -t debugfs debugfs /sys/kernel/debug

$ cat /sys/kernel/debug/gpio

Regards

AnilKumar

 Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

The TRM counts from 1 but Linux counts from 0. Try 96 in Linux for 97 in the TRM.

I've not used gpiochip registers much. Their main purpose seems to be to give the GPIO number ranges. Useful for GPIO expanders.

Each kernel version has different GPIO options. In your kernel source, see Documentation/gpio.txt. Later kernel versions add interrupt handling, ie edge, poll(). Google for code examples. Search term of "/sys/class/gpio". Lots out there.

Anil said:

Note: Always its better to make a different post which better than posting in a "Answered question"

Normally I would but this is exactly my context, and besides some of the info wasn't correct.  Too bad you can't 'un-verify', I think it would be good here.

Anil said:

Run these commands for knowing what are the GPIO's already requested in the drivers, which can not controlled from user space.

wow, this is great info, thanks!

This is what I get:

GPIOs 0-31, DaVinci:

GPIOs 32-63, DaVinci:
 gpio-36  (USB1 VBUS
          ) out hi
 gpio-38  (mdio_clk_en         ) out hi
 gpio-40  (lcd pwr
            ) out hi
 gpio-47  (lcd bl
             ) out hi

GPIOs 64-95, DaVinci:

GPIOs 96-127, DaVinci:
 gpio-109 (USB1 OC             ) in  lo irq-210 edge-both

GPIOs 128-143, DaVinci:

That should be OK for GPIO97, huh? (though, it makes me want to go back and check the lcd stuff because I thought I disabled all of it).

Norman Wong said:

The TRM counts from 1 but Linux counts from 0. Try 96 in Linux for 97 in the TRM.

Thanks, that was the trick.  The user manual counts GPIO from 1, Linux from 0.  Not documented anywhere in TI's stuff.

Obviously, I'm using TI provided kernel, in my case from dvsdk 4.02 currently. 

Hi bowerymarc,

Make sure that, no other driver is modifying the same pinmux register after your settings.

check the pinmux register value in the kernel,

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!