RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4

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

 



Hi,
>Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on
> RTL-1.4
> 
> Felipe Balbi wrote:
> > On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote:
> > > MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels
> are
> > > simultaneously enabled which results in DMA lockup.
> >
> > I've seen it on rtl1.8 also if I remember correctly.
> >
> 
> I'm fairly certain that this is not the case with RTL1.8, and if it is I'm
> very
> much interested in getting to the bottom of it. Do you have a test case
> that reproduces the lockup? Or a description of your use-case, or
> a register dump at failure, or any other clues?
> 

Felipe,

I have also not seen lockup issue on rtl1.8. Can you provide more detail
on your test case as Anand asked?

> > > Use system DMA for all RX channels as a workaround of this issue as
> this
> > > will have minimal throughput overhead based on the fact that Rx
> transfers
> > > are done in DMA mode-0 on OMAP34x/35x platforms.
> > >
> > > Another approach to use PIO mode in opposite direction would increase
> the
> > > cpu loading and thus using system DMA is preferred workaround.
> > >
> > > Signed-off-by: Anand Gadiyar <gadiyar@xxxxxx>
> > > Signed-off-by: Ajay Kumar Gupta <ajay.gupta@xxxxxx>
> >
> > I think falling back to pio is better than this patch.
At the cost of cpu, which certainly is not preferred.

>> It will most likely be only one transfer.

How about host mode with multiple devices connected and doing transfers?
Falling back to PIO would kill the cpu.

>> Another approach is to allocate dma channels on a transfer basis.

Can you elaborate this?

>> This is way too big of a problem.


If we think of the scenarios in host mode then certainly using system DMA is
best approach.

-Ajay
> Which one is better depends on how many endpoints are doing,
> transfers in parallel, I suppose.
> 
> I did post the a patch for the other approach (to fall back to PIO).
> I haven't received a response to that yet. I'm okay with either approach.
> 
> 
> - Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux