Re: Interrupt issue in twl4030_keypad

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 12, 2011 at 9:12 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> On Mon, Dec 12, 2011 at 08:30:49PM +0200, Felipe Contreras wrote:
>> The short version is this: either we revert this patch[1], or we apply
>> this patch series[2], as well as its essential fixes[3].
>>
>> The long version is this. There's a synchronization issue with the
>> current keypad driver and twl core; the irq is marked as handled even
>> though the thread that is supposed to handle it hasn't run yet, and
>> since it's clear-on-read, and it hasn't been read, it's detected
>> again, so they keypad driver receives two interrupt callbacks instead
>> of one, and in the second one reads nothing from the i2c register, so
>> a key release is assumed. This makes key-presses as simple as shift+a
>> impossible.
>>
>> In other words, it's totally unreliable. This might not be isolated to
>> the keypard driver, but other "nested" interrupts from twl core that
>> started using request_threaded_irq prematurely (before it was
>> supported by the twl core). But at least I haven't tried those.
>>
>> This patch was applied on 2.6.33, which means all versions before 3.2
>> are affected, including 3.1.
>>
>> What do you think about fixing this on stable kernels?
>
> I believe Samuel has already applied those to the MFD tree.

Yeap, I think Linus' tree is going to be fine (3.2), but I'm trying to
find out what to do with previous kernels: as in, what should be done
for stable trees.

> The funny part is that those patches were pending on linux-omap for over 2
> months I have refreshed them over and over again and asked for help from
> other people to test.

You mean these patches? [1] There's nothing wrong with pushing them
forward, but I'm actually talking about this one [2].

> Everything went smooth on my simple beagle board with no keypad and I
> couldn't see any issues, unfortunately.

That's because you didn't get a single interrupt. You could have added
a BUG() on handle_twl4030_pih() and you still wouldn't have noticed
anything.

> Still, 2 months is a whole lot of time to NAK a patch, but nobody said
> anything so, of course,

It's actually almost 2 years :)

> Samuel assumed it was ok and, like I said above, it worked for my simple GPIO
> usecase with beagleboard.

Well, for 3.2 I think the situation is fine, but that's not what I'm
talking about. About your GPIO tests, are you sure you got the
interrupts through twl4030 irq handling?

Cheers.

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/59958
[2] http://article.gmane.org/gmane.linux.kernel/932255

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux