De-glitch of gpio in kernel

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

How does the linux kernel de-glich gpio inputs from switches?

This is a loaded question as I'm seeing lengthy bursts of glitches on the SD card detect line on insert and remove events. The line is a direct connection to the AVR32 with a 47k pullup. (based on the stk1000 circuit diagram)

I notice the kernel does not have the gpio glitch filter enabled for the detect line, but turning it on did not help. Not really surprising as the glitches are much longer than 1 master clock cycle.

The attached picture demonstrates a typical removal event. Full scale is 500us.

I followed the code as far as the interrupt routine - which has no glitch rejection as it simply samples the line level. I'm hoping there's more to it than that, but I could not see where else any de-glitching would be occurring.

Attachment(s): 

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

Yes, there will be glitches, but does it introduce a problem? The interrupt for card detect is AFAIK a bit slow, so it de-glitches by itself.

Hans-Christian

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

How slow is a bit slow? It could be important.

My simple view of what happens goes like this.... An interrupt will be fired by the first transition. The interrupt routine samples the gpio pin but due to the glitches this is almost a random value*. If it happens to be the same as the cached value the interrupt returns without doing anything. The interrupt can be fired again by more edges in the burst, but there is no way to be sure it will see the final level. (* assuming the interrupt latency is sub 0.5 milliseconds)

What I experience is that the kernel misses SD card insert and remove event fairly often (by evidence of watching the /dev/mmcblk* entries, and messages in dmesg. I can't be sure that the glitches are the cause, but I don't see why I should not blame them yet.

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

Weird, I have yet to see this behavior on the NGW100. Do you use the NGW100 or your own design?

FYI: card detection does not work on STK1000, the schematics here is wrong. Pull-down to ground on a ground signal ;)

Hans-Christian

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

I think I said: The line is a direct connection to the AVR32 with a 47k pullup. (based on the stk1000 circuit diagram).

Is the circuit or kernel different on the NGW100?

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

On the STK1000, there is a 47k pulldown to ground, which results in a non working card detect (and write protect) signal. The NGW100 has 47k pullups.

Hmmm... looking at the schematics for both STK1000 and NGW100, I can not see why it should not work on STK1000. I think I have to look at the slot-connector again tomorrow.

Hans-Christian

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

Remember I'm not on an STK1000 - it's just based on the STK1000 (but with 47k pull up of course). Also my sd-slot connector is mechanically different. It might be cheaper and bounce more - I would not be surprised.

I'll try to get a probe on a modified STK1000 and see if I get the same problem.

Last Edited: Fri. Feb 15, 2008 - 10:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems like I have to eat my own dog food, since my colleague has experienced that card removal is not always detected :twisted:

A solution would be to add a timer or an additional tasklet to do this, and turn of the interrupt while waiting. Should not be that hard to implement, perhaps I get time tomorrow :)

Hans-Christian

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

Thanks. I'm actually glad you've been able to confirm the effect - perhaps it's just more obvious for me (due to my different receptacle/switch), but please don't eat dog food.

If/when you do have something I'll be first in line to test it :D I'll eat my hat if that does not fix it :shock:

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

Perhaps simply moving the code that reads the pin state into the tasklet would help. I suspect that the tasklet gets executed too quickly for this to work in all cases, so we probably need a timer or workqueue to delay the readout. Disabling the interrupt in the mean time is probably a good idea too.

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

Looking at the experimental results I have one would need a delay of at least 0.5ms, probably more to be safe. From experience with switches in general, de-bounce circuits need to operate with about 5ms to 10ms delays.

As this is from a user event, a delay of 100ms is probably negligible from this stand point. So it would be safe to aim for anything from around 10ms to 100ms.

hce, did you find time to look at an implementation?