All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Mack <zonque@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Sven Neumann <s.neumann@raumfeld.com>,
	Olof Johansson <olof@lixom.net>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Eric Miao <eric.y.miao@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Emulating level IRQs
Date: Sun, 05 Aug 2012 18:22:51 +0200	[thread overview]
Message-ID: <501E9DDB.3020807@gmail.com> (raw)
In-Reply-To: <500EE314.7040708@gmail.com>

On 24.07.2012 20:01, Daniel Mack wrote:
> On 23.07.2012 18:51, Dmitry Torokhov wrote:
>> On Thu, Jul 19, 2012 at 05:36:12PM +0200, Daniel Mack wrote:
> 
>>> Ok, finally I found some time. In general, the patch works fine. The
>>> only detail I had to amend was the irqflags, which were changed from
>>> IRQF_TRIGGER_RISING/IRQF_TRIGGER_FALLING to
>>> IRQF_TRIGGER_HIGH/IRQF_TRIGGER_LOW, which doesn't work as the PXA can't
>>> deal with level-based IRQs. Changing this back to RISING/FALLING makes
>>> the driver work again.
>>
>> Hmm, but that would mean we need to restore reading the data in open()
>> to make sure we re-arm IRQ in case somebody touched the screen before it
>> was opened by userspace...
> 
> I had another look at this and don't really know what to do here. We
> definitely need level interrupts for this device as the interrupt line's
> level is the only that tells us when we can stop reading from the
> device. So it's not just the start condition that bites us here.
> 
> I copied some people that might help find a solution.
> 
> To summarize the problem: The EETI touchscreen is a device that asserts
> a GPIO line when it has events to deliver and waits for I2C commands to
> empty its buffers. When there are no more buffered events, it will
> de-assert the line.
> 
> This device is connected to a PXA GPIO that is only able to deliver edge
> IRQs, and the old implemenation was to wait for an interrupt and then
> read data as long as the IRQ's corresponding GPIO was asserted. However,
> expecting that an IRQ is mappable to a GPIO is not something we should
> do, so the only clean solution is to teach the PXA GPIO controller level
> IRQs.
> 
> So it boils down to the question: Is there any easy and generic way to
> emulate level irq on chips that don't support that natively?

Otherwise, we would need some sort of generic irq_to_gpio() again, and
the interrupt line the driver listens to must have support for that sort
of mapping.

Any opinion on this, anyone?



Thanks,
Daniel


  parent reply	other threads:[~2012-08-05 16:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-07  5:40 [PATCH] Input: eeti_ts: Mark as CONFIG_BROKEN Olof Johansson
2012-04-07  7:02 ` Dmitry Torokhov
2012-04-07 18:38   ` Sven Neumann
2012-04-07 20:32     ` Olof Johansson
2012-04-07 20:32       ` Olof Johansson
2012-04-07 21:04       ` Joachim Eastwood
2012-04-07 21:04         ` Joachim Eastwood
2012-04-07 21:04         ` Joachim Eastwood
2012-04-09  2:28       ` Haojian Zhuang
2012-04-09  2:28         ` Haojian Zhuang
2012-04-10 10:10       ` Russell King - ARM Linux
2012-04-10 10:10         ` Russell King - ARM Linux
2012-04-10 16:01         ` Dmitry Torokhov
2012-04-10 16:01           ` Dmitry Torokhov
2012-05-03  4:36     ` Dmitry Torokhov
2012-07-13  7:01       ` Dmitry Torokhov
2012-07-15 18:21         ` Daniel Mack
2012-07-17 12:59         ` Daniel Mack
2012-07-19 15:36           ` Daniel Mack
2012-07-23 16:51             ` Dmitry Torokhov
2012-07-23 17:58               ` Daniel Mack
2012-07-24 18:01               ` Emulating level IRQs (was: Re: [PATCH] Input: eeti_ts: Mark as CONFIG_BROKEN) Daniel Mack
2012-07-24 18:58                 ` Mark Brown
2012-08-05 16:22                 ` Daniel Mack [this message]
2012-08-05 16:56                   ` Emulating level IRQs Haojian Zhuang
2012-08-05 17:56                     ` Daniel Mack
2012-08-06  1:45                       ` Eric Miao
2012-08-06 16:36                         ` Mark Brown
2012-08-07 15:19                           ` Daniel Mack

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=501E9DDB.3020807@gmail.com \
    --to=zonque@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=eric.y.miao@gmail.com \
    --cc=haojian.zhuang@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=s.neumann@raumfeld.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.