[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

Subbrathnam, Swaminathan swami.iyer at ti.com
Thu Nov 26 21:37:57 EST 2009


Sergei,

Another option is to have the cppi-generic code reside in the musb directory itself.  We do not have other peripherals such as Ethernet using cppi4.1 infrastructure in the near future.  Given this I think it will be better to locate this code in the "drivers/usb/musb" directory itself and decide on any relocation later if the need arises (which I feel is remote).

regards
swami

________________________________________
From: Sergei Shtylyov [sshtylyov at ru.mvista.com]
Sent: Friday, November 27, 2009 1:00 AM
To: Russell King - ARM Linux
Cc: Gupta, Ajay Kumar; Hilman, Kevin; davinci-linux-open-source at linux.davincidsp.com; linux-usb at vger.kernel.org; david-b at pacbell.net; stanley.miao; Subbrathnam, Swaminathan; linux-arm-kernel at lists.infradead.org; dan.j.williams at intel.com; maciej.sosnowski at intel.com
Subject: Re: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

Hello.

Russell King - ARM Linux wrote:

>>>>Is there any updated patch on cppi4.1 core also?

>>>Is there _any_ cppi4.1 core patch anywhere?  Not according to google.

>>Russell,

>>Here is the latest version of cppi4.1 core.
>>http://patchwork.kernel.org/patch/46698/

[...]

>>>If it's a USB DMA device (from the patches I can find, that seems to be
>>>the case) then why can't it live in drivers/usb or drivers/dma ?
>>
>>CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
>>currently only USB is using it but in future even Ethernet devices may use it.

> drivers/dma does seem to be the right place for this.

    Russell, it makes me wonder why drivers/dma/ seemed the right place to
you, just because of the name? :-)
    After spending some time on studying the infrastructure there I came to
conclusion that this is not the right place because all the controllers
supported there have features like memory-to-memory transfers or even RAID
function offloading -- which CPPI 4.1 totally lacks (it's there purely to
serve the peripherals).
    Adding drivers/dma/ people to this discussion in hopes they can correct
me (or support me :-)...

WBR, Sergei


More information about the linux-arm-kernel mailing list