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

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

 



Hi Torben,

On 6/24/2014 6:31 PM, Torben Hohn wrote:
On Wed, Jun 18, 2014 at 11:28:25AM +0200, Daniel Mack wrote:
Hi,
Hi Daniel,

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?

Note that these patches are to be applied on top of my musb/cppi41
cleanup series that I sent ~3 weeks ago.
Could you test, whether this commit also fixes your problem ?
https://lkml.org/lkml/2014/6/20/598


Theoretically it looks fine. But unfortunately the SoC with musb/cppi41 is a single core.



--
-George

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




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

  Powered by Linux