NGW GPIO changes as of 2.6.22

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

For those who don't monitor the avr32linux kernel mailing list it is worth mentioning that as of Linux kernel version 2.6.22 the way you drive the LEDs on the NGW has changed.

The configfs interface that so many have been grappling with across so many different threads and wiki pages is no longer available by default, though it can be compiled in with an edit of the kernel config, board code and a kernel recompile.

Instead the LEDs are hooked in to the kernel LED framework. This framework means that you now use /sys/class/leds to access them and you can hook them up to a number of triggers. As a demonstration you can hook an LED to a heartbeat trigger and watch it flash away nicely :)

Full details in this thread of the mailing list archives: http://avr32linux.org/archives/k...

This change does mean that the BSP2.0 startup scripts will fail on the GPIO init which can look scary but don't worry, it's nothing fatal unless you are using the gpio interface for things other than LEDs ^^

Post here if you have any further questions and if you see wiki docco anywhere, please update it (I'll be doing the same on any I come across :) )

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi !

I've got a question ! ^^ ( put my hand up and wait to be selected )

how can we control LED's with sys/class/leds if leds is a directory and if there's nothing in leds ?

Thank for the answer ^^ :D

I'm 18 years old, I've pass all my english course with great notes, but now I need the experience :lol: so please ^^' Give me a little chance :roll:.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, they're only defaults. They can be changed. I don't think it was intentional to leave out the GPIO_LEDS from the defconfig, although in the long run, I expect the GPIO /dev interface to become less relevant.

As for the leds directory being empty...well, I don't know about that. Probably a missing driver or something? Did the defconfig leave out the gpio-leds driver too...?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The thing is that the relevant patches haven't yet merged ... the GPIO leds driver just barely missed the 2.6.22 merge window, so it should merge soon (after 2.6.22-git5) along with the NGW leds patch, which updates the defconfig. Until BOTH of those patches merge, the sysfs leds directory will be empty. Once that merges, kernels will have three leds in sysfs, with "sys" doing a heartbeat.

I don't know what other trees have (or don't have), since I usually track git.kernel.org ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But normally if I do the atngw100_defconfig I'm supposed to have my LED activated with GPIO ?

Why does I have :

 * setting hostname ...          'ngw.example.net'
 * network loopback ...          [ OK ]
 * starting syslogd ...          [ OK ]
 * log messages to syslog ...    [ OK ]
 * starting klogd ...            [ OK ]
 * set mdev hotplug ...          [ OK ]
 * mdev ...                      [ OK ]
 * probing modules ...           [ MISSING ]
 * mounting filesystems:         [ FAILED ]  <------
 * network ...                   [ OK ]
 * enable ipv4 forwarding ...    [ OK ]
 * iptables postrouting ...      [ MISSING ]
 * starting dnsmasq ...          [ OK ]
 * starting dropbear ...         [ OK ]
 * starting telnetd ...          [ OK ]
 * starting inted ...            [ OK ]
 * starting httpd ...            [ OK ]
 * get board type for GPIO ...   'NGW' 
 * setup GPIO boot LED ...       [ FAILED ]  <------

Anyone have any ideas ?

thanks in advance ^^

PS: I'm using the 2.6.22 ATMEL version with their patch include.

I'm 18 years old, I've pass all my english course with great notes, but now I need the experience :lol: so please ^^' Give me a little chance :roll:.

Last Edited: Tue. Jul 17, 2007 - 06:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Normally, before 2.6.22, now they are controlled by the LEDs driver.

The startup scripts really only fit to the previous kernel :/

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

? ok ? so we normally need to update the u-boot...no...I'll pass my turn for this one.

But can they be controlled with the GPIO ?
why does I can't interact with it ?
nothing happen when I do

cat /dev/urandom > /dev/gpio1
-------
cat /dev/urandom > /dev/gpio2
-------
echo "0x80000" >/dev/gpio1
echo "0x00008" >/dev/gpio1
-------
echo "0x80000" >/dev/gpio2
echo "0x00008" >/dev/gpio2

Does I need to interact with them via /sys/class/leds ?
How ? I've tried to interact by there before but I can't open these files...if I remember...I'll try it again but it would be appreciated to have a confirmation ^^'

Thanks =D

Alexandre

---------EDIT-------------

I've tried with the sys/class/leds/...
and I receive :

-sh: cannot create /sys/class/leds/a: Is a directory 

so I can't interact with them this way....Ah !

I'm 18 years old, I've pass all my english course with great notes, but now I need the experience :lol: so please ^^' Give me a little chance :roll:.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what's *in* the /sys/class/leds/a directory? A bunch of files, right? One of them controls brightness ... the standard way that LEDs get controlled

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Satroyd wrote:
? ok ? so we normally need to update the u-boot...no...I'll pass my turn for this one.
No need to update uboot.
Satroyd wrote:
But can they be controlled with the GPIO ?
why does I can't interact with it ?
The gpio dev driver is no longer in by default. If you want this to work you'll need to just go in to your kernel config and enable the dev interface by hand. If you want to have the LEDs on it again you'll need to prevent them being claimed by the LED driver in the board setup code.
Satroyd wrote:
Does I need to interact with them via /sys/class/leds ?
Yes, that's how you're supposed to fiddle with LEDs now. Have a look in the /sys/class/leds/a directory, you should have a bunch of files to which you can write params. It won't work the same way as the dev interface, i.e. you won't be able to `cat /dev/urandom > /sys/class/leds`. As a test, try `echo heartbeat > /sys/class/leds//trigger`. I'm not at my dev compy at the moment so can't remember the device name, just ls /sys/class/leds. You will then hook a heartbeat trigger to the LED device and should see the led turning on and off slowly.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oh... :o now I see ^^'
We control the leds with a hexadecimal code ?
What's the range or.....how do we use these file?
I try to understand....it's 32 bit so I think that if I do
echo 0xFFFFFFFF > /sys/class/leds/a/trigger
nothing happen...but I already know it before I do...so complicated for nothing ^^'

is there any tutorial about how to use this new configuration ?

thanks
Alexandre.

I'm 18 years old, I've pass all my english course with great notes, but now I need the experience :lol: so please ^^' Give me a little chance :roll:.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not exactly, try echo heartbeat > /sys/class/leds/a/trigger :)

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I've donne it but if I want to control the led like I want...not just by doing a heart....how do I proceed?

Thanks, Alexandre

I'm 18 years old, I've pass all my english course with great notes, but now I need the experience :lol: so please ^^' Give me a little chance :roll:.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there are some files in /sys/class/leds// for controlling intensity. I can not remember what they are called now.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

/sys/class/leds//a/......
/sys/class/leds//b/......
/sys/class/leds//sys/....
-brightness
-device
-subsystem
-trigger
-uevent

I try to understand how to control the intensity( I can surely do it with "brightness ? right ? ), and how I can decide when the LED will turn on and off...

Anyone know how ?

thanks ^^
Alexandre

I'm 18 years old, I've pass all my english course with great notes, but now I need the experience :lol: so please ^^' Give me a little chance :roll:.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do a "cat /sys/class/leds//trigger"

Then you can see the different triggers available, the one selected will have [] around it. Select the one reasonable for being able to adjust brightness directly, it is not heartbeat or timer, can not remember right now.

Then do a "echo 0 > /sys/class/leds//brightness" and equal "echo 0xff > /sys/class/leds//brightness". I at least think brightness is given from 0 to 0xff. "cat /sys/class/leds//brightness" should give you some idea.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh now this is nice ! Intelligent !

But I'll try it later because I need to drink some water in the following second ...gasp ! ^^'

Thanks hce ! ^^

I'm 18 years old, I've pass all my english course with great notes, but now I need the experience :lol: so please ^^' Give me a little chance :roll:.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I'm on 2.6.22.atmel3 here, my LEDs do work perfectly (I can make them all beat like a heart, or control all manually). Now: How do I use the GPIO-pins to read buttons/switches? Does the wiki-page https://www.avrfreaks.net/wiki/index.php/Documentation:NGW/NGW100_Switched_Input still wirk with my kernel? If not: How do I do it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It works, but you can't use GPIO lines that are already used for something else. In other words, you can't use the GPIO /dev stuff to read/write the pins that are being used for the leds (just like you can't and never could mess with the MACB pins, for example.)

If you disable the LED setup code in the kernel, you can use those pins as GPIOs too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For buttons/switches, try drivers/input/keyboard/gpio_keys.c ... you'll get standard input devices.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I've got a button working now as I want it, /dev/gpio-devices are actually quite nice for what I need them but I'll have a look at the gpio_keys, too. Thanks for the hint.