On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote: > On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
