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.
Daniel
Attachment:
signature.asc
Description: OpenPGP digital signature
