There exist systems with multiple DMA controllers with different
capabilities. For example, on some sh-mobile / rmobile systems there are
DMA controllers, whose channels can be configured to be used with
SD- and MMC-host controllers, serial ports etc. Besides there are also
DMA controllers, that can only be used for one special function, e.g.,
for USB. In such cases the DMA client filter function can just choose
to specify to the DMA driver, which channel it needs. Then the
.device_alloc_chan_resources() method of the DMA driver will check,
whether it can provide that dunction. If not, it will fail and the loop
in __dma_request_channel() will continue to the next DMA device, until
it finds a suitable one. This works fine with just one minor glitch:
the kernel logs error messages like
dmaengine: failed to get <channel name>: (-<error code>)
after each such non-critical failure. This patch lowers priority of
this message to the debug level.
Reported-by: Kuninori Morimoto <[email protected]>
Signed-off-by: Guennadi Liakhovetski <[email protected]>
---
Morimoto-san, I don't expect this patch to fail;), but if you like, you
could give it a short spin and send your "tested-by" in reply to this
mail.
Thanks
Guennadi
drivers/dma/dmaengine.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 8bcb15f..f7f21a5 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -509,8 +509,8 @@ struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn fn, v
dma_chan_name(chan));
list_del_rcu(&device->global_node);
} else if (err)
- pr_err("dmaengine: failed to get %s: (%d)\n",
- dma_chan_name(chan), err);
+ pr_debug("dmaengine: failed to get %s: (%d)\n",
+ dma_chan_name(chan), err);
else
break;
if (--device->privatecnt == 0)
--
1.7.2.5
Dear Guennadi, all
> There exist systems with multiple DMA controllers with different
> capabilities. For example, on some sh-mobile / rmobile systems there are
> DMA controllers, whose channels can be configured to be used with
> SD- and MMC-host controllers, serial ports etc. Besides there are also
> DMA controllers, that can only be used for one special function, e.g.,
> for USB. In such cases the DMA client filter function can just choose
> to specify to the DMA driver, which channel it needs. Then the
> .device_alloc_chan_resources() method of the DMA driver will check,
> whether it can provide that dunction. If not, it will fail and the loop
> in __dma_request_channel() will continue to the next DMA device, until
> it finds a suitable one. This works fine with just one minor glitch:
> the kernel logs error messages like
>
> dmaengine: failed to get <channel name>: (-<error code>)
>
> after each such non-critical failure. This patch lowers priority of
> this message to the debug level.
>
> Reported-by: Kuninori Morimoto <[email protected]>
> Signed-off-by: Guennadi Liakhovetski <[email protected]>
> ---
>
> Morimoto-san, I don't expect this patch to fail;), but if you like, you
> could give it a short spin and send your "tested-by" in reply to this
> mail.
Thanks.
I tested this patch.
I don't know that the dmaengine design,
but this patch remove non-critical error message from USB-DMAC for me.
I tested it on mackerel board + renesas_usbhs + USB-DMAC
Tested-by: Kuninori Morimoto <[email protected]>
Best regards
--
Kuninori Morimoto
On Tue, Jun 21, 2011 at 9:19 AM, Kuninori Morimoto
<[email protected]> wrote:
>
> Dear Guennadi, all
>
>> There exist systems with multiple DMA controllers with different
>> capabilities. For example, on some sh-mobile / rmobile systems there are
>> DMA controllers, whose channels can be configured to be used with
>> SD- and MMC-host controllers, serial ports etc. Besides there are also
>> DMA controllers, that can only be used for one special function, e.g.,
>> for USB. In such cases the DMA client filter function can just choose
>> to specify to the DMA driver, which channel it needs. Then the
>> .device_alloc_chan_resources() method of the DMA driver will check,
>> whether it can provide that dunction. If not, it will fail and the loop
>> in __dma_request_channel() will continue to the next DMA device, until
>> it finds a suitable one. This works fine with just one minor glitch:
>> the kernel logs error messages like
>>
>> dmaengine: failed to get <channel name>: (-<error code>)
>>
>> after each such non-critical failure. This patch lowers priority of
>> this message to the debug level.
>>
>> Reported-by: Kuninori Morimoto <[email protected]>
>> Signed-off-by: Guennadi Liakhovetski <[email protected]>
>> ---
>>
>> Morimoto-san, I don't expect this patch to fail;), but if you like, you
>> could give it a short spin and send your "tested-by" in reply to this
>> mail.
>
> Thanks.
> I tested this patch.
>
> I don't know that the dmaengine design,
> but this patch remove non-critical error message from USB-DMAC for me.
> I tested it on mackerel board + renesas_usbhs + USB-DMAC
>
> Tested-by: Kuninori Morimoto <[email protected]>
So I too gave the USBHS + USBHS-DMAC patches a go on top of
linux-3.0-rc and they seem to work as expected.
Without "[PATCH] dmaengine: failure to get a specific DMA channel is
not critical" applied I get the following log:
/ # echo /dev/mtdblock4 > /sys/devices/platform/renesas_usbhs.1/gadget/lun0/file
[hook up laptop to the USB gadget port]
/ # dmaengine: failed to get dma0chan4: (-22)
dmaengine: failed to get dma1chan0: (-22)
dmaengine: failed to get dma2chan0: (-22)
dmaengine: failed to get dma3chan0: (-22)
dmaengine: failed to get dma0chan4: (-22)
dmaengine: failed to get dma1chan0: (-22)
dmaengine: failed to get dma2chan0: (-22)
dmaengine: failed to get dma3chan0: (-22)
g_mass_storage gadget: high speed config #1: Linux File-Backed Storage
With this patch applied the "dmaengine: failed to get..." messages all go away.
Tested-by: Magnus Damm <[email protected]>
Cheers,
/ magnus
On Wed, 2011-06-22 at 10:49 +0900, Magnus Damm wrote:
> On Tue, Jun 21, 2011 at 9:19 AM, Kuninori Morimoto
> <[email protected]> wrote:
> >
> > Dear Guennadi, all
> >
> >> There exist systems with multiple DMA controllers with different
> >> capabilities. For example, on some sh-mobile / rmobile systems there are
> >> DMA controllers, whose channels can be configured to be used with
> >> SD- and MMC-host controllers, serial ports etc. Besides there are also
> >> DMA controllers, that can only be used for one special function, e.g.,
> >> for USB. In such cases the DMA client filter function can just choose
> >> to specify to the DMA driver, which channel it needs. Then the
> >> .device_alloc_chan_resources() method of the DMA driver will check,
> >> whether it can provide that dunction. If not, it will fail and the loop
> >> in __dma_request_channel() will continue to the next DMA device, until
> >> it finds a suitable one. This works fine with just one minor glitch:
> >> the kernel logs error messages like
> >>
> >> dmaengine: failed to get <channel name>: (-<error code>)
> >>
> >> after each such non-critical failure. This patch lowers priority of
> >> this message to the debug level.
> >>
> >> Reported-by: Kuninori Morimoto <[email protected]>
> >> Signed-off-by: Guennadi Liakhovetski <[email protected]>
> >> ---
> >>
> >> Morimoto-san, I don't expect this patch to fail;), but if you like, you
> >> could give it a short spin and send your "tested-by" in reply to this
> >> mail.
> >
> > Thanks.
> > I tested this patch.
> >
> > I don't know that the dmaengine design,
> > but this patch remove non-critical error message from USB-DMAC for me.
> > I tested it on mackerel board + renesas_usbhs + USB-DMAC
> >
> > Tested-by: Kuninori Morimoto <[email protected]>
>
> So I too gave the USBHS + USBHS-DMAC patches a go on top of
> linux-3.0-rc and they seem to work as expected.
> Without "[PATCH] dmaengine: failure to get a specific DMA channel is
> not critical" applied I get the following log:
>
> / # echo /dev/mtdblock4 > /sys/devices/platform/renesas_usbhs.1/gadget/lun0/file
>
> [hook up laptop to the USB gadget port]
>
> / # dmaengine: failed to get dma0chan4: (-22)
> dmaengine: failed to get dma1chan0: (-22)
> dmaengine: failed to get dma2chan0: (-22)
> dmaengine: failed to get dma3chan0: (-22)
> dmaengine: failed to get dma0chan4: (-22)
> dmaengine: failed to get dma1chan0: (-22)
> dmaengine: failed to get dma2chan0: (-22)
> dmaengine: failed to get dma3chan0: (-22)
> g_mass_storage gadget: high speed config #1: Linux File-Backed Storage
>
> With this patch applied the "dmaengine: failed to get..." messages all go away.
>
> Tested-by: Magnus Damm <[email protected]>
Applied Thanks.
--
~Vinod