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

[#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