diff mbox

dmaengine: failure to get a specific DMA channel is not critical

Message ID Pine.LNX.4.64.1106201657280.11365@axis700.grange (mailing list archive)
State Not Applicable
Headers show

Commit Message

Guennadi Liakhovetski June 20, 2011, 3:02 p.m. UTC
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 <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---

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(-)

Comments

Kuninori Morimoto June 21, 2011, 12:19 a.m. UTC | #1
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 <kuninori.morimoto.gx@renesas.com>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> 
> 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 <kuninori.morimoto.gx@renesas.com>

Best regards
--
Kuninori Morimoto
 
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vinod Koul June 24, 2011, 10:45 a.m. UTC | #2
On Wed, 2011-06-22 at 10:49 +0900, Magnus Damm wrote:
> On Tue, Jun 21, 2011 at 9:19 AM, Kuninori Morimoto
> <kuninori.morimoto.gx@renesas.com> 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 <kuninori.morimoto.gx@renesas.com>
> >> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >> ---
> >>
> >> 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 <kuninori.morimoto.gx@renesas.com>
> 
> 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 <damm@opensource.se>
Applied Thanks.
diff mbox

Patch

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)