Re: [RFC] Teach drivers/media/IR/ir-raw-event.c to use durations

["David Härdeman" <david@hardeman.nu>]

On Wed, Apr 07, 2010 at 06:20:07AM -0400, Andy Walls wrote:
> On Tue, 2010-04-06 at 11:26 -0300, Mauro Carvalho Chehab wrote:
> > 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.

This sounds very similar to winbond-cir (the hardware parts that is, 
basically until and including item 5, line 1). The mceusb HW does 
something similar...it sends usb packets with a couple of pulse/space 
duration measurements (of 50us resolution IIRC)...and it automatically 
enters an inactive state after 10000 us of silence.

The ir_raw_event_duration() function of my patch is intended for exactly 
this kind of hardware (which I mentioned in my reply to Mauro which I 
just sent out).

The question is though, is the kfifo and work handler really 
necessary?

-- 
David Härdeman
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html