On Tue, Dec 06, 2016 at 01:14:20PM +0000, M?ns Rullg?rd wrote:
quoted
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 doesnt 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.
--
M?ns Rullg?rd
On Wed, Dec 07, 2016 at 04:45:58PM +0000, M?ns Rullg?rd wrote:
Vinod Koul [off-list ref] writes:
quoted
On Tue, Dec 06, 2016 at 01:14:20PM +0000, M?ns Rullg?rd wrote:
quoted
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 doesnt 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
On Wed, Dec 07, 2016 at 04:45:58PM +0000, M?ns Rullg?rd wrote:
quoted
Vinod Koul [off-list ref] writes:
quoted
On Tue, Dec 06, 2016 at 01:14:20PM +0000, M?ns Rullg?rd wrote:
quoted
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.
On Thu, Dec 8, 2016 at 11:54 AM, Mason [off-list ref] wrote:
On 08/12/2016 11:39, Vinod Koul wrote:
quoted
On Wed, Dec 07, 2016 at 04:45:58PM +0000, M?ns Rullg?rd wrote:
quoted
Vinod Koul [off-list ref] writes:
quoted
On Tue, Dec 06, 2016 at 01:14:20PM +0000, M?ns Rullg?rd wrote:
quoted
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?
Can you fall back to PIO if requesting a channel fails?
Alternatively, dma_request_chan() could always succeed, and
dmaengine_prep_slave_sg() could fail if the channel is currently not
available due to a limitation on the number of active channels, and
the driver could fall back to PIO for that transfer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Dec 08, 2016 at 11:54:51AM +0100, Mason wrote:
On 08/12/2016 11:39, Vinod Koul wrote:
quoted
On Wed, Dec 07, 2016 at 04:45:58PM +0000, M?ns Rullg?rd wrote:
quoted
Vinod Koul [off-list ref] writes:
quoted
On Tue, Dec 06, 2016 at 01:14:20PM +0000, M?ns Rullg?rd wrote:
quoted
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.
That is correct
Am I supposed to busy wait in my driver's DMA function
until a channel becomes available?
If someone else is using the channels then the bust wait will not help, so
in this case you should fall back to PIO, few drivers do that
I don't understand how the multiplexing of few memory
channels to many clients is supposed to happen efficiently?
To make it efficient, disregarding your Sbox HW issue, the solution is
virtual channels. You can delink physical channels and virtual channels. If
one has SW controlled MUX then a channel can service any client. For few
controllers request lines are hard wired so they cant use any channel. But
if you dont have this restriction then driver can queue up many transactions
from different controllers.
--
~Vinod