Re: [PATCH v2 0/2] usb musb/cppi41: Address issues with isochronous audio endpoints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 30, 2014 at 09:16:01PM +0200, Daniel Mack wrote:
> On 06/30/2014 07:54 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Fri, Jun 20, 2014 at 09:14:34AM +0530, George Cherian wrote:
> >> On 6/20/2014 3:50 AM, Daniel Mack wrote:
> >>> Hi,
> >>>
> >>> I've been debugging issues with musb in host mode and both full-speed
> >>> and high-speed USB audio devices with cppi41 DMA mode enabled.
> >>>
> >>> The effect that was observed with full-speed devices was that CPU load
> >>> went up to 100% due to the dma channels dma_completion work struct.
> >>> For FS devices, the MUSB_TXCSR_TXPKTRDY bit that signals the FIFO's
> >>> emptyness takes a long time to be cleared, and if the worker function
> >>> determines that it's still set, it will re-queue the work immediately,
> >>> which effectively results in a busy poll that renders the system
> >>> unusable. There are audible crackles on the output, and every bit of
> >>> extra load will distort the audio stream even more.
> >>>
> >>> The work struct was introduced by 1af54b7a40 ("usb: musb: musb_cppi41:
> >>> Handle ISOCH differently and not use the hrtimer."), apparantly in
> >>> order to mitigate an "unreliable" behaviour of the driver.
> >>>
> >>> Geroge, do you recall which problems you saw, which device you tested
> >>> with and what the effect of this patch was for you? I'm asking because
> >>> I suspect the issue in fact lies in the hrtimer interval setup and can
> >>> hence be fixed well without the extra worker.
> >>>
> >>> Sebastian's patch to implement that timer (a655f481d: "usb: musb:
> >>> musb_cppi41: handle pre-mature TX complete interrupt") expressed some
> >>> uncertainty about the chosen value of 140us, and suspected that there's
> >>> a relation between the dma burst size and the minimum time value.
> >>>
> >>> Hence, I'm sending two patches. The first one reverts 1af54b7a40 as it
> >>> causes trouble with FS audio devices, and the seconds addresses the
> >>> issue by tweaking the hrtimer settings instead. This seems to work fine
> >>> with both FS and HS audio devices now.
> >>>
> >>> George, could you give this a try with your original test case?
> >>
> >> Yes, I would do by this weekend and update.
> >> Sorry that am lil busy with some trainings.
> > 
> > Do we have any new developments here ?
> > 
> 
> FWIW, I now got back positive results from Sebastian, who tests these
> patches extensively.

cool, I'll add these to my 'testing/next' branch.


-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux