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,

>-----Original Message-----
>From: linux-usb-owner@xxxxxxxxxxxxxxx 
>[mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Gupta, Ajay Kumar
>Sent: Thursday, May 13, 2010 9:53 AM
>To: Gadiyar, Anand; me@xxxxxxxxxxxxxxx
>Cc: linux-usb@xxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx
>Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra 
>DMA issue on RTL-1.4
>
>Hi,
>>Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra 
>DMA issue 
>>on
>> RTL-1.4

>
>Felipe,
>
>> > > 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?

It might be good idea to allocate the dma channels on tarnsfer basis as Felipe
Suggested. The musb driver allocates dma channels for the first 8 enabled 
endpoints and  higher endpoints works in PIO mode. 
For system dma if there are more nummber of Rx endpoints enabled but not used for data 
Transfer you might end up having many sdma channles allocated biut not used which will
Impact in the system of not utilizing the sdma channels effectively.

~Hema

>>> 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-usb" in the body of a message to 
>majordomo@xxxxxxxxxxxxxxx More majordomo info at  
>http://vger.kernel.org/majordomo-info.html
>--
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