Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Jon Smirl <jonsmirl@gmail.com>]

On Tue, Dec 8, 2009 at 9:07 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
>>
>>>> What is the interface for attaching an in-kernel decoder?
>>> IMO, it should use the kfifo for it. However, if we allow both raw data and
>>> in-kernel decoders to read data there, we'll need a spinlock to protect the
>>> kfifo.
>>
>> This may be an option, but I think we should be able to attach protocol
>> decoders in parallel, directly to the IRQ handler. At least with RC-5
>> (that's what I personally use) it means reliable decoding, no need for
>> any timeouts, the code is clean, fast (can be a part of hard IRQ
>> handler) and simple.
>>
>> The decoder needs something like
>>       rc5_signal_change(ptr, space_or_mark, microseconds).
>>
>> At least mark->space or space->mark events must be reported. For better
>> reliability, both of them.
>
> If you use a kfifo to store the event (space_or_mark, timestamp),
> the IRQ handler can return immediately, and a separate kernel thread
> can do the decode without needing to touch at the IRQ. It also helps to
> have a decoder independent of the kernel driver.

The first version of my code ran the decoders from the IRQ. That
wasn't a good model for sharing decoders between drivers. So I
switched to using a kernel thread. There is also the problem of
handing decoded events off up the chain. You can't do that from IRQ
context.

If I remember correctly the kernel thread would run approximately two
times per IR message received. But sometimes it would only run once.
It's a random function of the load on the system. The kernel thread
empties the FIFO and sends the pulses in parallel to the decoders.

Code for doing this is in the patches I posted. I wasn't aware of
kfifo when I wrote them so I coded my own fifo.

-- 
Jon Smirl
jonsmirl@gmail.com