[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130805174031.GA20093@core.coreip.homeip.net>
Date: Mon, 5 Aug 2013 10:40:31 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: "Zubair Lutfullah :" <zubair.lutfullah@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>, jic23@....ac.uk,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org, gregkh@...uxfoundation.org,
Russ.Dill@...com
Subject: Re: [PATCH 1/2] input: ti_tsc: Enable shared IRQ for TSC
On Mon, Aug 05, 2013 at 06:02:02PM +0100, Zubair Lutfullah : wrote:
> On Mon, Aug 05, 2013 at 09:12:56AM -0700, Dmitry Torokhov wrote:
> > > > Touchscreen and ADC share the same IRQ line from parent MFD core.
> > > > Previously only Touchscreen was interrupt based.
> > > > With continuous mode support added in ADC driver, driver requires
> > > > interrupt to process the ADC samples, so enable shared IRQ flag bit for
> > > > touchscreen.
> > > >
> > > > @@ -260,8 +260,18 @@ static irqreturn_t titsc_irq(int irq, void *dev)
> > > > unsigned int fsm;
> > > >
> > > > + /*
> > > > + * ADC and touchscreen share the IRQ line.
> > > > + * FIFO1 threshold, FIFO1 Overrun and FIFO1 underflow
> > > > + * interrupts are used by ADC,
> > > > + * hence return from touchscreen IRQ handler if FIFO1
> > > > + * related interrupts occurred.
> > > > + */
> > > > + if ((status & IRQENB_FIFO1THRES) ||
> > > > + (status & IRQENB_FIFO1OVRRUN) ||
> > > > + (status & IRQENB_FIFO1UNDRFLW))
> > > > + return IRQ_NONE;
> > > > + else if (status & IRQENB_FIFO0THRES) {
> >
> > What happens if both parts have data at the same time? Can both
> > IRQENB_FIFO1THRES and IRQENB_FIFO0THRES be signalled? What will happen
> > in this case?
>
> If ADC is sampling and someone is touching the TSC, both interrupts
> can signal so closely that for the purpose of the kernel,
> they can be seen as signaled together.
>
> FIFO 1 used only by ADC and FIFO1THRES handler is inside the iio/adc driver
> FIFO 0 used only by TSC and FIFO0THRES handler is inside the input/touchscreen
>
> Note: These are level interrupts.
>
> I would like some input on how to handle such a situation.
It looks like you need to have smart demultiplexing in MFD core of your
driver instead of relying on shared interrupt handler.
Another option would be to check "your" bits, handle the data, clear the
status and then check bits again and return IRQ_NONE instead of
IRQ_HANDLED if other guys bits are set, but it is way too ugly.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists