Tearing down DMA transfer setup after DMA client has finished
Mason
slash.tmp at free.fr
Thu Dec 8 02:54:51 PST 2016
On 08/12/2016 11:39, Vinod Koul wrote:
> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>
>> Vinod Koul <vinod.koul at intel.com> writes:
>>
>>> On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote:
>>>>
>>>> That's not going to work very well. Device drivers typically request
>>>> dma channels in their probe functions or when the device is opened.
>>>> This means that reserving one of the few channels there will inevitably
>>>> make some other device fail to operate.
>>>
>>> No that doesn't make sense at all, you should get a channel only when you
>>> want to use it and not in probe!
>>
>> Tell that to just about every single driver ever written.
>
> Not really, few do yes which is wrong but not _all_ do that.
Vinod,
Could you explain something to me in layman's terms?
I have a NAND Flash Controller driver that depends on the
DMA driver under discussion.
Suppose I move the dma_request_chan() call from the driver's
probe function, to the actual DMA transfer function.
I would want dma_request_chan() to put the calling thread
to sleep until a channel becomes available (possibly with
a timeout value).
But Maxime told me dma_request_chan() will just return
-EBUSY if no channels are available.
Am I supposed to busy wait in my driver's DMA function
until a channel becomes available?
I don't understand how the multiplexing of few memory
channels to many clients is supposed to happen efficiently?
Regards.
More information about the linux-arm-kernel
mailing list