From: Roland Stigge <stigge@antcom.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: srinivas.bakki@nxp.com, linux-doc@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org, kevin.wells@nxp.com,
linux-mtd@lists.infradead.org, dwmw2@infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] MTD: LPC32xx MLC NAND driver
Date: Tue, 15 May 2012 17:49:56 +0200 [thread overview]
Message-ID: <4FB27B24.3030604@antcom.de> (raw)
In-Reply-To: <20120515143428.GC13860@n2100.arm.linux.org.uk>
Hi Russell!
Thanks for your notes!
On 05/15/2012 04:34 PM, Russell King - ARM Linux wrote:
> On Tue, May 15, 2012 at 04:23:52PM +0200, Roland Stigge wrote:
>> +static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
>> + void *mem, int len, enum dma_transfer_direction dir)
>> +{
>> + struct nand_chip *chip = mtd->priv;
>> + struct lpc32xx_nand_host *host = chip->priv;
>> + struct dma_async_tx_descriptor *desc;
>> + int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
>> + int res;
>> + dma_cookie_t cookie;
>> +
>> + host->dma_slave_config.direction = dir;
>> + host->dma_slave_config.src_addr = dma;
>> + host->dma_slave_config.dst_addr = dma;
>> + if (dmaengine_slave_config(host->dma_chan, &host->dma_slave_config)) {
>> + dev_err(mtd->dev.parent, "Failed to setup DMA slave\n");
>> + return -ENXIO;
>> + }
>
> The 'direction' argument should be ignored by all modern DMA engine
> drivers
Good - this way, I can move dmaengine_slave_config() to the dma_setup()
function, i.e., to probe().
However, I needed to set it there to some initial value (e.g., DMA_DEV_TO_MEM) -
otherwise the amba-pl08x driver didn't accept it. Is this a bug in the pl08x
driver?
Can we remove the .direction element from the struct dma_slave_config to prevent
others from making the same mistakes? Or is it useful for sth. else still?
>> +
>> + sg_init_one(&host->sgl, mem, len);
>> +
>> + res = dma_map_sg(host->dma_chan->device->dev, &host->sgl, 1, dir);
>
> Also note that dma transfer directions and dma data directions are
> different things. You shouldn't mix the two.
Thanks for pointing this out - I wasn't aware that the distinction between the
two is so important. Also consider e.g.:
arch/arm/mm/dma-mapping.c:
/**
* dma_map_sg - map a set of SG buffers for streaming mode DMA
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
* @sg: list of buffers
* @nents: number of buffers to map
* @dir: DMA transfer direction
^^^^^^^^^^^^^^^^^^^^^^
*
[...]
* Device ownership issues as mentioned for dma_map_single are the same
* here.
*/
int dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir)
^^^^^^^^^^^^^^^^^^^^^^^
;-)
Roland
WARNING: multiple messages have this Message-ID (diff)
From: stigge@antcom.de (Roland Stigge)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] MTD: LPC32xx MLC NAND driver
Date: Tue, 15 May 2012 17:49:56 +0200 [thread overview]
Message-ID: <4FB27B24.3030604@antcom.de> (raw)
In-Reply-To: <20120515143428.GC13860@n2100.arm.linux.org.uk>
Hi Russell!
Thanks for your notes!
On 05/15/2012 04:34 PM, Russell King - ARM Linux wrote:
> On Tue, May 15, 2012 at 04:23:52PM +0200, Roland Stigge wrote:
>> +static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
>> + void *mem, int len, enum dma_transfer_direction dir)
>> +{
>> + struct nand_chip *chip = mtd->priv;
>> + struct lpc32xx_nand_host *host = chip->priv;
>> + struct dma_async_tx_descriptor *desc;
>> + int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
>> + int res;
>> + dma_cookie_t cookie;
>> +
>> + host->dma_slave_config.direction = dir;
>> + host->dma_slave_config.src_addr = dma;
>> + host->dma_slave_config.dst_addr = dma;
>> + if (dmaengine_slave_config(host->dma_chan, &host->dma_slave_config)) {
>> + dev_err(mtd->dev.parent, "Failed to setup DMA slave\n");
>> + return -ENXIO;
>> + }
>
> The 'direction' argument should be ignored by all modern DMA engine
> drivers
Good - this way, I can move dmaengine_slave_config() to the dma_setup()
function, i.e., to probe().
However, I needed to set it there to some initial value (e.g., DMA_DEV_TO_MEM) -
otherwise the amba-pl08x driver didn't accept it. Is this a bug in the pl08x
driver?
Can we remove the .direction element from the struct dma_slave_config to prevent
others from making the same mistakes? Or is it useful for sth. else still?
>> +
>> + sg_init_one(&host->sgl, mem, len);
>> +
>> + res = dma_map_sg(host->dma_chan->device->dev, &host->sgl, 1, dir);
>
> Also note that dma transfer directions and dma data directions are
> different things. You shouldn't mix the two.
Thanks for pointing this out - I wasn't aware that the distinction between the
two is so important. Also consider e.g.:
arch/arm/mm/dma-mapping.c:
/**
* dma_map_sg - map a set of SG buffers for streaming mode DMA
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
* @sg: list of buffers
* @nents: number of buffers to map
* @dir: DMA transfer direction
^^^^^^^^^^^^^^^^^^^^^^
*
[...]
* Device ownership issues as mentioned for dma_map_single are the same
* here.
*/
int dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir)
^^^^^^^^^^^^^^^^^^^^^^^
;-)
Roland
WARNING: multiple messages have this Message-ID (diff)
From: Roland Stigge <stigge@antcom.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
dwmw2@infradead.org, kevin.wells@nxp.com, srinivas.bakki@nxp.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] MTD: LPC32xx MLC NAND driver
Date: Tue, 15 May 2012 17:49:56 +0200 [thread overview]
Message-ID: <4FB27B24.3030604@antcom.de> (raw)
In-Reply-To: <20120515143428.GC13860@n2100.arm.linux.org.uk>
Hi Russell!
Thanks for your notes!
On 05/15/2012 04:34 PM, Russell King - ARM Linux wrote:
> On Tue, May 15, 2012 at 04:23:52PM +0200, Roland Stigge wrote:
>> +static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
>> + void *mem, int len, enum dma_transfer_direction dir)
>> +{
>> + struct nand_chip *chip = mtd->priv;
>> + struct lpc32xx_nand_host *host = chip->priv;
>> + struct dma_async_tx_descriptor *desc;
>> + int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
>> + int res;
>> + dma_cookie_t cookie;
>> +
>> + host->dma_slave_config.direction = dir;
>> + host->dma_slave_config.src_addr = dma;
>> + host->dma_slave_config.dst_addr = dma;
>> + if (dmaengine_slave_config(host->dma_chan, &host->dma_slave_config)) {
>> + dev_err(mtd->dev.parent, "Failed to setup DMA slave\n");
>> + return -ENXIO;
>> + }
>
> The 'direction' argument should be ignored by all modern DMA engine
> drivers
Good - this way, I can move dmaengine_slave_config() to the dma_setup()
function, i.e., to probe().
However, I needed to set it there to some initial value (e.g., DMA_DEV_TO_MEM) -
otherwise the amba-pl08x driver didn't accept it. Is this a bug in the pl08x
driver?
Can we remove the .direction element from the struct dma_slave_config to prevent
others from making the same mistakes? Or is it useful for sth. else still?
>> +
>> + sg_init_one(&host->sgl, mem, len);
>> +
>> + res = dma_map_sg(host->dma_chan->device->dev, &host->sgl, 1, dir);
>
> Also note that dma transfer directions and dma data directions are
> different things. You shouldn't mix the two.
Thanks for pointing this out - I wasn't aware that the distinction between the
two is so important. Also consider e.g.:
arch/arm/mm/dma-mapping.c:
/**
* dma_map_sg - map a set of SG buffers for streaming mode DMA
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
* @sg: list of buffers
* @nents: number of buffers to map
* @dir: DMA transfer direction
^^^^^^^^^^^^^^^^^^^^^^
*
[...]
* Device ownership issues as mentioned for dma_map_single are the same
* here.
*/
int dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir)
^^^^^^^^^^^^^^^^^^^^^^^
;-)
Roland
next prev parent reply other threads:[~2012-05-15 15:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 14:23 [PATCH] MTD: LPC32xx MLC NAND driver Roland Stigge
2012-05-15 14:23 ` Roland Stigge
2012-05-15 14:34 ` Russell King - ARM Linux
2012-05-15 14:34 ` Russell King - ARM Linux
2012-05-15 14:34 ` Russell King - ARM Linux
2012-05-15 15:49 ` Roland Stigge [this message]
2012-05-15 15:49 ` Roland Stigge
2012-05-15 15:49 ` Roland Stigge
2012-05-15 15:56 ` Roland Stigge
2012-05-15 15:56 ` Roland Stigge
2012-05-15 15:56 ` Roland Stigge
2012-05-15 16:00 ` Russell King - ARM Linux
2012-05-15 16:00 ` Russell King - ARM Linux
2012-05-15 16:00 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB27B24.3030604@antcom.de \
--to=stigge@antcom.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dwmw2@infradead.org \
--cc=kevin.wells@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=srinivas.bakki@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.