Chronological Thread 

< Chronological >      < Thread >

---

On Wed, Jan 20, 2010 at 6:15 PM, Shane Blackett <shane at blackett.co.nz>
wrote:
...
>>> I have two ideas I'm thinking about for errors at the moment. ?It
>>> proabably
>>> seems related to the speed the data is coming, I wonder if either in the
>>> actual imon device or possibly in the USB HUB that the device is
>>> connected
>>> to?
>>
>> Dunno. I floated a test patch out there that simply added (iirc) an
>> mdelay(10) to the end of send_packet() to see if stalling return from
>> that function a bit effectively throttled how fast we were sending
>> data to the display, to the point where it could actually keep up. I
>> can't remember a definitive reply that said it didn't help, so if you
>> can slap that in and test it out, it would be much appreciated.
>
> Yep I read this thread as I got there from the urb(-22) search I did early
> on.
> I tried several values for mdelay in these routines (it is currently 4 I
> think). ?I tried it exactly as suggested in the patch by the person
> debugging it and in the slightly different form that you recommended.
> Unfortunately it didn't seem to make much difference to me.

Okay, good to at least have concrete confirmation of that. :)

> I'll play around with such a delay again a bit more rigourously when I get a
> chance and then list what I have tried here.

I keep forgetting... There's another change that might help... When I
sent the new input layer imon driver[*] upstream for review, it was
pointed out that the atomic_foo() calls *probably* aren't doing what
they were intended to do -- which is safeguard against having multiple
writes in flight at the same time. I rewrote that bit of code to use
memory barriers, which should properly remedy any caching effects, so
we always get a consistent picture of whether or not there's actually
write traffic in flight already... Unfortunately, I don't have a patch
against lirc_imon handy at the moment, but it should be fairly trivial
to port:

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=commitdiff;h=75c2fe9117de538386c18231fa8521dd48ef7b59

[*] I've split off support for ffdc and newer devices that do onboard
decoding into a pure input layer driver, per some lirc discussion on
lkml, leaving lirc_imon to handle only the four very very old devices
that don't do onboard decoding. Not making this change in lirc cvs yet
though, only in my git tree...

--
Jarod Wilson
jarod at wilsonet.com

---

• [Lcdproc] Older vfd lockups, Shane Blackett, 01/17/2010
  • [Lcdproc] Older vfd lockups, jk, 01/18/2010
    • [Lcdproc] Older vfd lockups, Shane Blackett, 01/20/2010
      • [Lcdproc] Older vfd lockups, jk, 01/20/2010
        • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/20/2010
          • [Lcdproc] Older vfd lockups, Shane Blackett, 01/20/2010
            • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/20/2010
              • [Lcdproc] Older vfd lockups, Shane Blackett, 01/21/2010
              • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/21/2010
            • [Lcdproc] Older vfd lockups, jk, 01/20/2010
          • [Lcdproc] Older vfd lockups, jk, 01/20/2010
            • [Lcdproc] Older vfd lockups, Jarod Wilson, 01/20/2010
              • [Lcdproc] Older vfd lockups, jk, 01/20/2010

---

Archive powered by MHonArc 2.6.18.