Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Fri, 2010-07-30 at 01:07 +0300, Maxim Levitsky wrote: 
> On Thu, 2010-07-29 at 17:57 -0400, Jarod Wilson wrote: 
> > On Thu, Jul 29, 2010 at 5:28 PM, Jarod Wilson <jarod@redhat.com> wrote:
> > > On Thu, Jul 29, 2010 at 11:04:47PM +0300, Maxim Levitsky wrote:
> > >> On Thu, 2010-07-29 at 21:35 +0200, Christoph Bartelmus wrote:
> > >> > Hi!
> > >> >
> > >> > Maxim Levitsky "maximlevitsky@gmail.com" wrote:
> > >> > [...]
> > >> > >>>>> Could you explain exactly how timeout reports work?
> > >> > [...]
> > >> > >>> So, timeout report is just another sample, with a mark attached, that
> > >> > >>> this is last sample? right?
> > >> > >>
> > >> > >> No, a timeout report is just an additional hint for the decoder that a
> > >> > >> specific amount of time has passed since the last pulse _now_.
> > >> > >>
> > >> > >> [...]
> > >> > >>> In that case, lets do that this way:
> > >> > >>>
> > >> > >>> As soon as timeout is reached, I just send lirc the timeout report.
> > >> > >>> Then next keypress will start with pulse.
> > >> > >>
> > >> > >> When timeout reports are enabled the sequence must be:
> > >> > >> <pulse> <timeout> <space> <pulse>
> > >> > >> where <timeout> is optional.
> > >> > >>
> > >> > >> lircd will not work when you leave out the space. It must know the exact
> > >> > >> time between the pulses. Some hardware generates timeout reports that are
> > >> > >> too short to distinguish between spaces that are so short that the next
> > >> > >> sequence can be interpreted as a repeat or longer spaces which indicate
> > >> > >> that this is a new key press.
> > >> >
> > >> > > Let me give an example to see if I got that right.
> > >> > >
> > >> > >
> > >> > > Suppose we have this sequence of reports from the driver:
> > >> > >
> > >> > > 500 (pulse)
> > >> > > 200000 (timeout)
> > >> > > 100000000 (space)
> > >> > > 500 (pulse)
> > >> > >
> > >> > >
> > >> > > Is that correct that time between first and second pulse is
> > >> > > '100200000' ?
> > >> >
> > >> > No, it's 100000000. The timeout is optional and just a hint to the decoder
> > >> > how much time has passed already since the last pulse. It does not change
> > >> > the meaning of the next space.
> > >>
> > >> its like a carrier report then I guess.
> > >> Its clear to me now.
> > >>
> > >> So, I really don't need to send/support timeout reports because hw
> > >> doesn't support that.
> > >>
> > >> I can however support timeout (LIRC_SET_REC_TIMEOUT) and and use it to
> > >> adjust threshold upon which I stop the hardware, and remember current
> > >> time.
> > >> I can put that in generic function for ene like hardware
> > >> (hw that sends small packs of samples very often)
> > >
> > > So... I presume this means a v3 patchset? And/or, is it worth merging
> > > patches 1, 2, 3, 6 and 7 now, then having you work on top of that?
> > 
> > This branch is a as-of-a-few-minutes-ago, up-to-date linuxtv
> > staging/other plus a few outstanding patches and your patches 1, 2, 3,
> > 6 and 7:
> 
> I am surely send V3 and likely V4.
> I changed many of my patches, 
> 
> I now  am chasing a very strange leak of samples I see. (sometimes,
> randomaly a sample goes missing, and that breaks in-kernel decoding...)
> It appears to be not my driver fault, nor fifo overflow...


Rolls eyes.... 


void ir_raw_event_handle(struct input_dev *input_dev)
{
struct ir_input_dev *ir = input_get_drvdata(input_dev);

if (!ir->raw)
return;

schedule_work(&ir->raw->rx_work);
}
EXPORT_SYMBOL_GPL(ir_raw_event_handle);


This is workqueue, so who said two of them can run at same time.....

Best regards,
Maxim Levitsky