USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi]

[Ian Lepore]

On Sat, 2014-05-10 at 15:50 +0200, Hans Petter Selasky wrote:
> On 05/10/14 14:24, Ian Lepore wrote:
> > On Sat, 2014-05-10 at 09:51 +0200, Hans Petter Selasky wrote:
> >> Hi,
> >>
> >> I've made one more patch to the DWC OTG driver. Nice if you can test
> >> that too.
> >>
> >> http://svnweb.freebsd.org/changeset/base/265806
> >>
> >> BTW: I think I've found what is causing the glitches when using USB
> >> audio devices:
> >>
> >> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c
> >> index 0490be7..de7f015 100644
> >> --- a/sys/arm/arm/machdep.c
> >> +++ b/sys/arm/arm/machdep.c
> >> @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate)
> >>    void
> >>    cpu_idle(int busy)
> >>    {
> >> -
> >> +#if 0
> >>           CTR2(KTR_SPARE2, "cpu_idle(%d) at %d",
> >>               busy, curcpu);
> >>    #ifndef NO_EVENTTIMERS
> >> @@ -442,6 +442,7 @@ cpu_idle(int busy)
> >>    #endif
> >>           CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done",
> >>               busy, curcpu);
> >> +#endif
> >>    }
> >>
> >>    int
> >>
> >>
> >> It appears that cpu_idle() is going to sleep when there are pending
> >> interrupts, and then waking up on the next timer IRQ! Can someone
> >> familiar with these parts of the kernel comment?
> >>
> >> Please try for yourself, with and without the patch above, using an USB
> >> audio device with the RPI-B!
> >>
> >> Still when the console is printing, there are significant glitches too
> >> :-) That's because the TTY layer is synchronously writing data to the
> >> serial line. That's OK for now.
> >>
> >> --HPS
> >
> > If there's an interrupt pending when the WaitForInterrupt instruction is
> > executed, the cpu doesn't go to sleep -- it acts like a nop.  I think
> > the problem might be that the device write that re-enables the interrupt
> > hasn't yet made it to the device when the cpu clock stops.
> >
> > I don't have any usb audio gear to test with, could you please test the
> > attached patch and see if it fixes the glitches?
> >
> > -- Ian
> >
> 
> Hi,
> 
> That code is not used with RPI so it makes no difference. 

Doh!  We have so much decoy code in freebsd-arm.

> I think we 
> need to do something like they are doing on x86, that the interrupts are 
> enabled the instruction before the sleep instruction. Else we can loose 
> interrupts. Can you write me a correct patch which implements that?
> 

ARM is not x86.  From the ARM ARM:

        When a processor issues a WFI instruction it can suspend
        execution and enter a low-power state. It can remain in that
        state until the processor detects a reset or one of the
        following WFI wake-up events:
      * an IRQ interrupt, regardless of the value of the CPSR.I bit.
      * an FIQ interrupt, regardless of the value of the CPSR.F bit.
      * an asynchronous abort, regardless of the value of the CPSR.A
        bit.
      * a debug event, when invasive debug is enabled and the debug
        event is permitted.

Not only is enabling interrupts before WFI not necessary, it may be
completely the wrong thing to do... if there's an interrupt pending it
will fire as soon as the cpsr.I bit is set, and the handler will run
before the WFI executes.  Depending on what the handler does maybe
putting the CPU to sleep isn't the right thing to do anymore -- the ISR
made something runnable that previously wasn't -- but upon return from
handling the interrupt we'll unconditionally go to sleep until the next
interrupt instead of returning to the scheduler which would now find new
non-idle work to do.

Note that in the linux implementation they actually go so far as adding
a comment to explain that the code doesn't disable interrupts because
it's expected that the caller has already done so:

https://github.com/torvalds/linux/blob/master/arch/arm/mm/proc-v6.S#L69

I wonder if this is related to some memory ordering trouble I've seen in
armv7, which I can't fully explain, but the attached patch makes it go
away (preventing spurious interrupts).  It'd be interesting to see if it
has any effect on this situation.

-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pmap_device_strongly_ordered.diff
Type: text/x-patch
Size: 581 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20140510/1faadd05/attachment.bin>