Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote: 
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> > I think you won't be able to fix the problem conclusively either way.  A
> > lot of how the chip's clocks should be programmed depends on how the
> > GPIOs are used and what crystal is used.
> >
> > I suspect many designers will use some reference design layout from ENE,
> > but it won't be good in every case.  The wire-up of the ENE of various
> > motherboards is likely something you'll have to live with as unknowns.
> >
> > This is a case where looser tolerances in the in kernel decoders could
> > reduce this driver's complexity and/or get rid of arbitrary fudge
> > factors in the driver.
> 
> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%).  The crystals used in electronics are accurate to
> 0.0001%+.  The 4% error in this driver is because the hardware is not
> being programmed accurately. This needs to be fixed in the driver and
> not in the upper layers.

Let me explain again.

I get samples in 4 byte buffer. each sample is a count of sample
periods.
Sample period is programmed into hardware, at 'ENE_CIR_SAMPLE_PERIOD'
(it is in us)

Default sample period is 50 us.

The error source isn't 'electronics' fault.
The device is microprocessor.
I don't read the samples 'directly' from hardware, but rather from ram
of that microprocessor.
I don't know how it samples the input.
A expiration of sample period might just cause a IRQ inside that
microprocessor, and it can't process it instantly. That is probably the
source of the delay.
Or something like that.

Best regards,
Maxim Levitsky