Re: [RFC v2] Another approach to IR

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Krzysztof Halasa wrote:
> Mauro Carvalho Chehab <mchehab@redhat.com> writes:
> 
>> Btw, looking at that code, while it is not impossible to split the 
>> IR pulse/space measures from the NEC decoder itself, and make it generic
>> to support other protocols, it is not a trivial task, and may result on
>> a less stable driver.
> 
> And it's not needed at all.
> Protocol decoders can be easily run in parallel, I've done it on saa713x
> and this is trivial at least there. Can do that when the lirc interface
> is available.

>> The advantage of the NEC decoding approach on saa7134 is that you know for
>> sure how much time it is required to get the entire code. So, the code 
>> can easily abort the reception of a bad code. The disadvantage is that 
>> only one protocol can be decoded at the same time.
> 
> This isn't a hard thing to fix.

Good to know. We're open to patches to improve it. 

The point is that we've got in the past several complains about saa713x
machines hanging due to IRQ's generated by IR sensor port. We ended by adding
an option to disable IR and a code at the driver that disables IR IRQ if it 
happens too often.

> 
>> The same problem also happens with almost all in-kernel drivers: the decoders
>> for raw mode were constructed to work with just one pulse/space code at the
>> same time. A conversion into a generic code can happen, but it will require
>> several tests to be sure that they won't cause undesirable side-effects.
> 
> IOW any such receiver has to be tested, sure.
> 
>> The advantage of hardware decoders is that you don't need to be polling the
>> IR serial port at a high rate, as you'll get directly the code. So, you'll
>> free the CPU to do something else.
> 
> Which device requires polling the port?
> Most are IRQ-driven, aren't they?

Most of the devices that have a hardware IR decodes needs polling. Most of they
simply outputs the scan code on some set of GPIO pins.

In general, the devices with the IR sensor connected to a GPIO pin are IRQ-driven.

Cheers,
Mauro.