Re: Allocating buffers for USB transfers (again)

[Sarah Sharp <sarah.a.sharp@linux.intel.com>]

On Fri, Aug 12, 2011 at 03:28:42AM +0200, Daniel Mack wrote:
> On Fri, Aug 12, 2011 at 1:50 AM, Matěj Laitl <matej@laitl.cz> wrote:
> > On 12. 8. 2011 Daniel Mack wrote:
> >> > This patch actually makes the sound playback _worse_. Now I get strange
> >> > squawks where previously at least first seconds of a song sounded
> >> > normally.
> >> >
> >> > However, I no longer get "zero length buffer submitted" or that "...
> >> > Weird." debug messages, only several megabytes of: (should I post these
> >> > somewhere?)
> >> >
> >> > xhci_hcd 0000:05:00.0: Giveback URB ffff880114cec000, len = 880,
> >> > expected = 1000, status = -115
> >> > xhci_hcd 0000:05:00.0: Giveback URB ffff880114740000, len = 352,
> >> > expected = 1000, status = -115
> >> > xhci_hcd 0000:05:00.0: underrun event on endpoint
> >>
> >> Might be the hardware doesn't like this. As I said, the patch is blindly
> >> written and I couldn't test it. Did you test this on a EHCI port as well?
> >
> > Good point, this patch distorts the playback also on the EHCI port. (the
> > playback seems to be 10 times slower than it should be)
> 
> And it is only this *last* patch that causes it, yes?
> 
> If that is the case, we need empty subframes in the middle of urbs,
> and we need to figure a way how to teach the XHCI driver to cope with
> that, too.

By empty subframes, you mean zero-length frame buffers in the middle of
the URB, correct?  Andiry and Alan had some suggestions for how to fix
that, so I'll try to cook up a patch tomorrow.  Then we'll have to
"unpeel" the debug patches and make sure the system is still usable.

Sarah Sharp