[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120330102554.GA22981@n2100.arm.linux.org.uk>
Date: Fri, 30 Mar 2012 11:25:54 +0100
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Guennadi Liakhovetski <g.liakhovetski@....de>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Vinod Koul <vinod.koul@...el.com>,
linux-kernel@...r.kernel.org,
Jassi Brar <jassisinghbrar@...il.com>,
Magnus Damm <magnus.damm@...il.com>,
Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to
__dma_request_channel()
On Fri, Mar 16, 2012 at 12:09:55PM +0100, Guennadi Liakhovetski wrote:
> 3. the wrapper, proposed by Russell, now calls dmaengine_slave_config(),
> which fails, because that's a wrong channel (hope I get this right this
> time - configuration has nothing to do with selection:-))
I keep saying this. Slave configuration has nothing to do with
channel selection. All it does is tell the DMA engine about the
essential details about the peripheral it's being asked to transfer
data with.
If a DMA engine itself doesn't support the peripheral, then none of
the channels on that DMA engine would support it - eg, if the peripheral
had a byte sized register but your DMA engine only supported word size,
that would be a valid reason to have slave_config() fail.
However, if that's the case why would you have wired the peripheral up
to such a DMA engine? And that's the hint here: you can't use any
peripheral with any DMA engine - there has to be physical handshaking
signals connecting the two together. And that's what actually controls
which DMA engines and DMA channels are suitable.
Not what the physical address or width or burst size required by the
peripheral. It's all to do with physical electrical signal routing.
The sooner you get this silly idea that dmaengine_slave_config() should
somehow be involved with DMA channel selection the better it will be
for everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists