FAQ: [#6432] System hangs after setting sysfs/class/gpio/gpioX/edge(2011)

Document created by Aaronwu Employee on Sep 11, 2013Last modified by Aaronwu Employee on Sep 11, 2013
Version 2Show Document
  • View in full screen mode

[#6432] System hangs after setting sysfs/class/gpio/gpioX/edge

Submitted By: Kolja Waschk

Open Date

2011-01-05 07:21:37    

Priority:

Medium     Assignee:

steven miao

Status:

Open     Fixed In Release:

N/A

Found In Release:

2010R1-RC5     Release:

Category:

N/A     Board:

Custom

Processor:

BF537     Silicon Revision:

0.3

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

2010R1-RC4

App binary format:

FDPIC     

Summary: System hangs after setting sysfs/class/gpio/gpioX/edge

Details:

 

While experimenting with the sysfs interface to my board's GPIOs, I experienced the following behaviour. It occurs always in this way on my board (which is quite similar to the BF537-STAMP). The first symptom is an irritating warning, the second symptom a total system lockup. Not sure if they are related. In detail:

 

/ # echo 29 > /sys/class/gpio/export

/ # echo in > /sys/class/gpio/gpio29/direction

/ # echo falling > /sys/class/gpio/gpio29/edge

bfin-gpio: GPIO 29 is already reserved by BFIN-GPIO! (Documentation/blackfin/bfin-gpio-notes.txt)

/ #

 

After setting the "edge", changing the I/O pin state externally would cause the system to hang. It won't respond anymore to key presses, network activity etc.

 

Before writing to "export", GPIO_29 was not claimed by any driver. After writing to "export", it shows up in /proc/gpio as claimed by BFIN-GPIO, type "GPIO INPUT". After writing to "edge", /proc/gpio becomes this:

 

/ #  cat /proc/gpio

GPIO_0:     bfin-uart         Peripheral

GPIO_1:     bfin-uart         Peripheral

GPIO_2:     bfin-uart         Peripheral

GPIO_3:     bfin-uart         Peripheral

GPIO_25:     BFIN-GPIO         GPIO OUTPUT

GPIO_29:     gpio-irq79 *         GPIO INPUT

GPIO_32:     bfin_mac         Peripheral

GPIO_33:     bfin_mac         Peripheral

GPIO_36:     bfin_mac         Peripheral

GPIO_37:     bfin_mac         Peripheral

GPIO_38:     bfin_mac         Peripheral

GPIO_40:     bfin_mac         Peripheral

GPIO_41:     bfin_mac         Peripheral

GPIO_46:     bfin_mac         Peripheral

GPIO_47:     bfin_mac         Peripheral

GPIO_48:     bfin_mac         Peripheral

GPIO_49:     bfin_mac         Peripheral

GPIO_50:     i2c-bfin-twi         Peripheral

GPIO_51:     i2c-bfin-twi         Peripheral

 

If you need more details to reproduce the effect,  please let me know.

 

Follow-ups

 

--- Kolja Waschk                                             2011-01-05 09:58:41

This seems to be dependent on I-Pipe (which comes with Xenomai) being enabled.

Without I-Pipe, it doesn't happen. I'll ask "upstream"...

 

 

--- Kolja Waschk                                             2011-08-17 11:36:22

Discussion about similar/same problem (when using gpio-keys):

 

https://mail.gna.org/public/xenomai-help/2011-08/msg00081.html

 

--- Kolja Waschk                                             2011-08-17 11:39:00

Phillippe Gerum writes [...] Most likely the low level interrupt path for gpios

is not ipipe-aware in this kernel, arch/blackfin/kernel/bfin_gpio.c might be at

fault [...]

 

--- Kolja Waschk                                             2011-08-18 07:12:39

With I-pipe, even for edge triggered interrupts, the desc->handle_irq is set

to handle_level_irq. This prevents

mach-common/ints-priority.c:bfin_gpio_mask_ack_irq() to correctly acknowledge

edge triggered interrupts, it seems.

 

Calling set_gpio_data(gpionr, 0) unconditionally (ie. independent from

desc->handle_irq setting) helps. The system will continue to run normally

even after keypress. But I'm not sure if this is correct for every situation.

 

 

--- steven miao                                              2011-08-30 03:08:45

Hi Kolja,

 

yes, it right, actually the irq type of gpio_29 is edge, the pin status is

sticky to 1 after asserted, it should be clear by set_gpio_data() to 0 to clear

sticky. or you can fix in __ipipe_ack_level_irq in kernel/irq/chip.c which

assigned by __fixup_irq_handler() in kernel/irq/chip.c in of patch as Phillippe

Gerum said.

 

-steven

 

--- steven miao                                              2011-09-16 02:51:06

fix in __ipipe_ack_level_irq() by __fixed_irq_handler()

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

ints-priority.c.patch    text/x-diff    430    Kolja Waschk

Attachments

Outcomes