Ticket #2185 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

AUX button makes interrupt storm

Reported by: vnevoa Owned by: openmoko-devel
Priority: normal Milestone:
Component: unknown Version: Om2008.9-dev
Severity: normal Keywords: AUX button interrupts
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible: always

Description

I have difficulty using the AUX button on my GTA02v5 to lock/unlock the phone.
When I press it, it locks, but when I release it, it unlocks again. Sometimes it works as intended, but most times it takes a handful of tries to (un)lock it.

This is a recent problem for me, but I can't decide if it is a hardware or software problem.

Looking at "/proc/interrupts", I can see an interrupt storm each time the button is pressed or released.

Initial state:
root@om-gta02:~# cat /proc/interrupts | grep AUX

50: 373 s3c-ext Neo1973 AUX button

Press the button:
root@om-gta02:~# cat /proc/interrupts | grep AUX

50: 375 s3c-ext Neo1973 AUX button

Release the button:
root@om-gta02:~# cat /proc/interrupts | grep AUX

50: 384 s3c-ext Neo1973 AUX button

So, pressing the button causes a couple of interrupts, and releasing it causes almost 10.

I expected the hardware to filter out these bounces. Is it a hardware or kernel problem?

Attachments

opkg list_installed.txt (45.1 KB) - added by vnevoa 6 years ago.
logread.txt (63.1 KB) - added by vnevoa 6 years ago.
dmesg.txt (11.5 KB) - added by vnevoa 6 years ago.

Change History

Changed 6 years ago by vnevoa

Changed 6 years ago by vnevoa

Changed 6 years ago by vnevoa

comment:1 Changed 6 years ago by arhuaco

vnevoa: I've been checking and I cannot reproduce the interrupt storm in a GTA02 (sometimes I get an extra IRQ but that's it, tested with 2.6.24 and 2.6.28). Could you help us testing a patch later to see if it solves the problem for you?

comment:2 Changed 6 years ago by andy

Nelson, just an idea from a different angle: the AUX key is pulled down by 100K, it probably means it falls down only quite slowly when the key is released. During that fall it could spew interrupts while it is in the middle area.

At the moment we don't apply GPIO pulldown on GPF6 which is AUX, if we did that we would decrease the pulldown to around a third of what it is now and reduce the problem if it comes from that direction. So maybe give that a try as well.

comment:3 Changed 6 years ago by vnevoa

Yes, of course I'll test whatever you need - as long as it is already compiled and not too tricky to install. ;)

I get the same behaviour under "Hackable:1": 2 interrupts on pressing, 10 on releasing. But since it is aparently using the same kernel as OM2008.12, this still doesn't separate HW from SW.

I tend to agree with Andy: given the GTA02's weak pull-downs and your phone not suffering the same problem, it feels more like my recently heavier usage of this button has started to show a manufacturing problem or a mechanical contact defect in my specific phone... but I'd like to be sure, of course! :)

comment:4 Changed 6 years ago by arhuaco

I get the same behaviour under "Hackable:1": 2 interrupts on pressing, 10 on releasing. But since it is aparently using the same kernel as OM2008.12, this still doesn't separate HW from SW.

It is hardware I think. I tried both new and old kernel. Perhaps something happened to the button. I'll try a software fix.

The pull-down thing did not work for me. This is the code I used for testing... I'm sending it in case someone can point out a mistake...

+#include <mach/regs-gpio.h>
+

static int neo1973kbd_probe(struct platform_device *pdev)
{

struct neo1973kbd *neo1973kbd;

@@ -355,6 +359,8 @@ static int neo1973kbd_probe(struct platform_device *pdev)

enable_irq_wake(keys[NEO1973_KEY_JACK].irq);


+ s3c2410_gpio_pullup(S3C2410_GPF6, 0);

return 0;

We might have to resort to what they do for neo1973kbd_headphone_irq. I think it is a similar case. I will send the URI of a compiled kernel so that you can try it out. It will be a new kernel (2.6.28). I think it might be easy to port to 2.6.24...

comment:5 Changed 6 years ago by arhuaco

vnevoa:

Here is the testing kernel. It has printks that you can check with "dmesg |tail". It should fix the issue I hope, it fixes the extra IRQs (actually 1) for me.

sha1sum : c4ff1d76b5f53c097803d95f27c4b222e22182ab
http://wiki.emqbit.com/tmp/uImage-moredrivers-GTA02_andy-tracking_21d2295ec0832028.bin

If you are using u-boot, you need to type this in the u-boot prompt:

setenv bootcmd setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel 0x300000\; bootm 0x32000000
saveenv

This will allow you to upload kernels bigger than 2MB.

In case this kernel does not play well with your rootfs you might tell us how things go analyzing dmesg only.

Thanks for testing :-)

comment:6 Changed 6 years ago by andy

Nelson the pullup thing is completely misleading... there are only pulldowns on s3c2442. So the semantic is set it to '1' to get a pullDOWN, crazy but true :-)

comment:7 Changed 6 years ago by arhuaco

Andy, I think I tried with 1 also :-) I'll check again in a while anyway just in case...

comment:8 Changed 6 years ago by andy

Well if you don't get much bouncing, you probably won't notice. If the spamming is due to our slowly falling through the transition region between 0 and 1 though, this should impact it. If the contact is physically bouncing on the reporter's device now, it won't make much difference either way. That you can't reproduce it suggests physical issue that your patch should solve.

comment:9 Changed 6 years ago by vnevoa

Tested you kernel image just now.

It's better, it actually allows me to lock/unlock around 80% of the times, but in reality it has just cut down a little bit on the number of interrupts in the burst - and made it an odd number. :)
The button pressing now generates 1 interrupt (occasionally 2), and releasing it generates 4 (occasionally 5) interrupts.

I'd agree my phone's button must be partially whacked, but you have to consider there may be others like mine out there - it is only 4 months old, it should not be exhibiting mechanical fatigue so soon - so this patch is kinda important. ;)

BTW, this kernel just gave me my first ever WSOD!... I have no idea how it happened, I touched the screen just when it was going dark and it went white and I had to remove the battery (no ssh, no nothing)... not a good sign.

comment:10 follow-up: ↓ 11 Changed 6 years ago by vnevoa

Oops, sorry, I only looked at the /proc/interrupts output.
Now I'm looking at the kernel messages.

When I press the AUX button, I get only 1 message:

"IRQ press:0"

When I release the button, I get 2 messages:

"IRQ press:0"
"IRQ press:1"

Now I see the Power button also behaves strangely, I think.
I press Power, and I get 3 kernel messages:

"INT1=0x80 INT2=0x02 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"

I release it, and I get another 3:

"INT1=0x00 INT2=0x01 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x80 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"

Is this supposed to happen?

comment:11 in reply to: ↑ 10 Changed 6 years ago by arhuaco

Replying to vnevoa:

Oops, sorry, I only looked at the /proc/interrupts output.

Yes, you will still get the IRQ storm there... the idea is to filter it.

Now I'm looking at the kernel messages.

When I press the AUX button, I get only 1 message:

"IRQ press:0"

When I release the button, I get 2 messages:

"IRQ press:0"
"IRQ press:1"

Ok. This device is asking for a state. I will program something better now... I think it is not hard to solve this.

In the mean time it will help us a lot if you test another image. It will print
every IRQ. I didn't make 2 images but one image and 2 modules. You will get a warning
when you remove the modules, I haven't researched that issue yet (it is not fatal but it needs to be fixed).

You will need to disable suspend in your distro (using the GUI I guess). This time we want to know the timings of the interrupts in order to tune the filter. I'm sending 2 modules. One of them has the pulldown, let's see if it makes a noticeable difference for you.

The idea is that for each module, you try this:

1) insert module.
2) press and release the button fast
3) wait about 1 second

please repeat 2 and 3 about 10 times.

4) remove the module
5) Do a "dmesg > module1" or "dmesg > module2"....

Then send us the dumps...

Please download from: http://wiki.emqbit.com/tmp/test2.tar
MD5SUMS:
840672c60dbd29cb98b58653aac75d6f module1.ko
224406385ed557181a6da4bfca152a49 module2.ko
0d4bec316e8c70d6bb9f561239ea0fcc uImage-moredrivers-GTA02_andy-tracking_1c16df7be9a83288.bin

Now I see the Power button also behaves strangely, I think.
I press Power, and I get 3 kernel messages:

"INT1=0x80 INT2=0x02 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"

I release it, and I get another 3:

"INT1=0x00 INT2=0x01 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
"INT1=0x80 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"

Is this supposed to happen?

I do not know... I will focus on the problem of the ticket first...

comment:12 Changed 6 years ago by arhuaco

vnevoa:

This kernel should fix AUX bouncing. It would be nice if you can confirm so that we can trust the patch.

http://wiki.emqbit.com/tmp/uImage-moredrivers-GTA02_andy-tracking_b6d1b1c2788c5903.bin

Once we know this problem is solved we'll check the power button issue.
It is solved for me but your problem was more serious.

Best regards.

comment:13 follow-up: ↓ 14 Changed 6 years ago by vnevoa

Yes, this kernel does the right thing for me. 100% accurate after about 30 clicks. :)

But it also makes my Neo go WSOD on resume, which never happened before... I hope it is just something temporary that you are aware of. :)

comment:14 in reply to: ↑ 13 Changed 6 years ago by arhuaco

Replying to vnevoa:

Yes, this kernel does the right thing for me. 100% accurate after about 30 clicks. :)

Yay! Thanks for testing :-) Then this ticket can be marked as resolved... We will use a similar logic for more buttons.

About the WSOD you might want to comment in this ticket (I seems to be relevant for that issue):

https://docs.openmoko.org/trac/ticket/1841

comment:15 Changed 6 years ago by wendy_hung

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.