All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.