From: Cory Maccarrone <darkstar6262@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Ferenc Wagner <wferi@niif.hu>,
linux-input@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH] Input: gpio-keys: Support for one-directional interrupts
Date: Wed, 9 Dec 2009 14:03:42 -0800 [thread overview]
Message-ID: <6cb013310912091403i3cb527caqa687487966bb232d@mail.gmail.com> (raw)
In-Reply-To: <20091209175831.GD4456@core.coreip.homeip.net>
On Wed, Dec 9, 2009 at 9:58 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Dec 09, 2009 at 08:15:26AM -0800, Cory Maccarrone wrote:
>> On Wed, Dec 9, 2009 at 3:32 AM, Ferenc Wagner <wferi@niif.hu> wrote:
>>
>> I'm fairly certain it wouldn't. Each of the interrupts on my hardware
>> has a corresponding bit in a control register that determines if it's
>> rising or falling-edge triggered -- thus the need for my patch. To
>> capture both directions, it's necessary to modify the control register
>> when a falling edge is detected, so that the corresponding rising edge
>> can be collected afterward.
>
> This kind of ugliness should be hidden in irqchip driver. See
> mfd/asic3.c for an example.
>
I would agree with that -- it should be possible to hide that away as
part of the functionality of the interrupt driver. Perhaps a fix to
the OMAP1 IRQ handling is warranted. I know there are some interrupts
that can do both directions out of the box, but that shouldn't be the
responsibility of each driver to know.
>> May I ask why you're thinking of
>> converting to level-triggering?
>>
>> Perhaps it would be better to provide an option in the platform_device
>> structure to set edge- or level-triggering, similar to the change I'm
>> proposing for interrupts that can only signal one way at a time.
>>
>
> Yes, we need a way fro platform code to specify desired interrupt flags
> but I don't believe we should be reconfiguring them on the fly.
>
If the ability to handle this type of interrupt transparently was
added to our board IRQ chip driver, this whole thing would be a
non-issue, as gpio-keys could request edge triggered falling and
rising at the same time, and the driver would Just Work.
I'll take a look and see how possible that would be to do. Looking
through the code for OMAP1's GPIO IRQ handlers, there's a note that
OMAP1 only supports edge triggering, so if gpio-keys were to move
exclusively to that, itwould stop working with those boards. But, it
may be possible to do the trigger flip in the chip driver, which would
make this patch unnecessary.
- Cory
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-12-09 22:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-05 22:38 [PATCH] Input: gpio-keys: Support for one-directional interrupts Cory Maccarrone
2009-12-09 11:32 ` Ferenc Wagner
2009-12-09 16:15 ` Cory Maccarrone
2009-12-09 17:58 ` Dmitry Torokhov
2009-12-09 22:03 ` Cory Maccarrone [this message]
2009-12-11 4:03 ` Cory Maccarrone
2010-01-09 17:56 ` Cory Maccarrone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6cb013310912091403i3cb527caqa687487966bb232d@mail.gmail.com \
--to=darkstar6262@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=wferi@niif.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).