Re: [RFC] Teach drivers/media/IR/ir-raw-event.c to use durations

[Jon Smirl <jonsmirl@gmail.com>]

On Wed, Apr 7, 2010 at 9:29 AM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> On the implementation I did, each event is passed to each decoder serialized (yet, as one keystroke
> is a series of events, it behaves as if they are processed in parallel). We might create separate
> kthreads for each decoder, and use a spinlock at kfifo, but I suspect that the end result will be
> very close and we'll have more threads interfering at the samples collect, especially on those
> (broken) hardware that don't have IRQ's to indicate a state transition, so the driver needs
> to poll the samples.

Polling should be the driver's problem. They can set up a timer
interrupt and do it that way. Do all of the protocols have a long
enough lead one for a timer tick to catch them? If so, look for it in
the timer event, then go into a polling loop. You'd be way better off
buying new hardware since your video is going to stop while this
pooling loop runs. Do modern serial ports interrupt on DTR or whatever
those Iguana devices use? What is an example of a polled input device?
I can't think of one, even IR diode on mic input is interrupt driven
(that require a special ALSA driver to pass the data into RC core).

No need to use different kthreads for each protocol decoder, but don't
lock up the default kernel thread waiting for a user space response.
What I meant by parallel was that pulses are fed one at a time into
each of the decoders, don't wait for a long space and then feed the
entire message into the decoders.

>
> --
>
> Cheers,
> Mauro
>



-- 
Jon Smirl
jonsmirl@gmail.com