From: Daniel Mack [mailto:dan...@zonque.org]
> On 06/19/2014 05:07 PM, Felipe Balbi wrote:
> > On Wed, Jun 18, 2014 at 11:36:43AM +0200, Daniel Mack wrote:
> >> On 06/18/2014 11:32 AM, David Laight wrote:
> >>> From: Of Daniel Mack
> >>>> Sent: 18 June 2014 10:28
> >>>> To: ba...@ti.com; george.cher...@ti.com; bige...@linutronix.de
> >>>> Cc: sebastian.reim...@googlemail.com; linux-usb@vger.kernel.org; Daniel
> >>>> Mack
> >>>> Subject: [PATCH 2/2] usb: musb: cppi41: fire hrtimer according to
> >>>> programmed channel length
> >>>>
> >>>> The musb/cppi41 code installs a hrtimer to work around DMA completion
> >>>> interrupts that have fired too early on AM335x hardware. This timer
> >>>> is currently programmed to first fire 140 nanoseconds after the DMA
> >>>> completion callback. According to the commit which introduced it
> >>>> (a655f481d83, "usb: musb: musb_cppi41: handle pre-mature TX complete
> >>>> interrupt"), that value is is considered a 'rule of thumb' that worked
> >>>> well with the test case described in the commit log.
> >>>>
> >>>> Test show, however, that for USB audio devices and much smaller packet
> >>>> sizes, the timer has to fire earlier in order to correctly handle the
> >>>> audio
> >>>> stream. The original test case had output transfer sizes of 1514 bytes,
> >>>> and
> >>>> a delay of 140 nanoseconds. For audio devices with 24 bytes channel
> >>>> size, 3
> >>>> nanoseconds seem to work well.
> >>>
> >>> You can't really mean nanoseconds?
> >>
> >> Microseconds of course. Thanks for the heads-up. Fixed locally.
> >
> > Are you sending another one or want me to fix the commit log when
> > applying here ?
>
> I was actually waiting for feedback on the patch before resending
> another version. In particular, I'd like to know whether George's test
> case still works with this patch applied.
>
> If nobody has objections, you fixing the commit log would of course be
> easiest, yes :)
IIRC there was a reference to nanoseconds inside the patch as well.
Possibly a variable name.
David
