On Tue, 2010-04-06 at 11:26 -0300, Mauro Carvalho Chehab wrote: > Hi David, > > I won't comment every single bits of the change, since we're more interested on the conceptual > aspects. > > > -int ir_raw_event_store(struct input_dev *input_dev, enum raw_event_type type) > > Don't remove the raw_event_store. It is needed by the hardware that gets events from > IRQ/polling. For sure another interface is needed, for the cases where the hardware pass their > own time measure, like cx18 (http://linuxtv.org/hg/~awalls/cx23885-ir2/rev/2cfef53b95a2). > > For those, we need something like: > > int ir_raw_event_time_store(struct input_dev *input_dev, enum raw_event_type type, u32 nsecs) > > Where, instead of using ktime_get_ts(), it will use the timing provided by the hardware. Just to clarify what Conexant hardware, and my current driver for it, is capable of: 1. It provides raw pulse (and space) width measurements. 2. Those measurements can have very high resoltuion (~37 ns IIRC) or very low resolution (usec or msec IIRC) depending on how the hardware clock dividers are set up. 3. The hardware provides a timeout when the measurment timer overflows, meaning that no edge happened for a very long time. This generates a special "overflow" measurment value and a receiver timeout interrupt. 4. The hardware has an 8 measurement deep FIFO, which the driver starts to drain whenever it is half full (i.e. pulse measurement data is delayed). This happens in response to a hardware FIFO service request interrupt. 5. The hardware FIFO is drained by the driver whenever an interrupt is received and the available measruement data is placed into a kfifo(). This will then signal a work handler that it has work to do. 6. Measurements are scaled to standard time units (i.e. ns) by the driver when they are read out of the kfifo() by a work handler. (No sense in doing time conversions in an interrupt handler). 7. The work handler then begins passing whatever measurements it has, one at a time, over to a pulse stream decoder. 8. If the pulse stream decoder actually decodes something, it is passed over to the input subsystem. I suspect this device's behavior is much closer to what the MCE-USB device does, than the raw GPIO handlers, but I don't really know the MCE-USB. Regards, Andy -- 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
