Message ID | Pine.LNX.4.64.1106201657280.11365@axis700.grange (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
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
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 --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)
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(-)