public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>,
	computersforpeace@gmail.com
Cc: dwmw2@infradead.org, matthias.bgg@gmail.com, robh@kernel.org,
	daniel.thompson@linaro.org, xiaolei.li@mediatek.com,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2/3] mtd: mediatek: driver for MTK Smart Device Gen1 NAND
Date: Tue, 15 Mar 2016 14:53:39 +0100	[thread overview]
Message-ID: <20160315145339.28d50175@bbrezillon> (raw)
In-Reply-To: <56E80C5F.2020406@linaro.org>

On Tue, 15 Mar 2016 09:21:35 -0400
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> wrote:

> On 03/15/2016 08:59 AM, Boris Brezillon wrote:
> > On Tue, 15 Mar 2016 08:28:37 -0400
> > Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org> wrote:
> >
> >> On 03/08/2016 11:24 AM, Boris Brezillon wrote:
> >>>> +static int mtk_nfc_write_page(struct mtd_info *mtd,
> >>>>> +			struct nand_chip *chip, const uint8_t *buf,
> >>>>> +			int oob_on, int page, int raw)
> >>>>> +{
> >>>>> +
> >>>>> +	struct mtk_nfc_host *host = nand_get_controller_data(chip);
> >>>>> +	struct completion *nfi = &host->nfi.complete;
> >>>>> +	struct device *dev = host->dev;
> >>>>> +	const bool use_ecc = !raw;
> >>>>> +	void *q = (void *) buf;
> >>>>> +	dma_addr_t dma_addr;
> >>>>> +	size_t dmasize;
> >>>>> +	u32 reg;
> >>>>> +	int ret;
> >>>>> +
> >>>>> +	dmasize = mtd->writesize + (raw ? mtd->oobsize : 0);
> >>>>> +
> >>>>> +	dma_addr = dma_map_single(dev, q, dmasize, DMA_TO_DEVICE);
> >>> buf is not guaranteed to be physically contiguous, so you can't just
> >>> use it with DMA without doing a few more verifications.
> >>>
> >>> In case you're interested in using a generic approach to do this
> >>> verification, you can have a look at this series [2].
> >>>
> >> unfortunately the internal dma controller does not support scatter gather
> >> operations (we need to DMA in/out of memory in a single shot)
> >> If we enable NAND_USE_BOUNCE_BUFFER, I think this guarantees that the buffer
> >> will be contiguous (since they are allocated with kmalloc)
> >> ...although maybe I should have the bounce buffers in the driver and allocate
> >> them with devm_get_free_pages instead
> >>
> >> would either of this would be acceptable?
> > Or you could test if the buffer is contiguous, and fallback to using
> > a bounce buffer (either an internal one or the generic one) if that's
> > not the case. Note that the proposed API can be improved to reject
> > non-contiguous buffers...
> 
> wouldn't that check be the same than the one done in the nand interface when
> NAND_USE_BOUNCE_BUFFER is enabled?
> IIRC virt_addr_valid() guarantees that the buffer is contiguous.

Correct, I forgot we had that test, and thought we were always using
the bounce buffer when NAND_USE_BOUNCE_BUFFER was set.
Still, in some cases, you might have vmallocated buffers that are
physically contiguous (say you have NAND page < PAGE_SIZE).

Anyway, I guess setting NAND_USE_BOUNCE_BUFFER and assuming the buf
passed to ->read/write_page() is always pointing to a physically
contiguous region is an acceptable option until we have this
mtd_map_buf() API ready.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2016-03-15 13:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 17:00 [RFC PATCH 0/3] MTK Smart Device Gen1 NAND support Jorge Ramirez-Ortiz
2016-03-02 17:00 ` [PATCH 1/3] mtd: mediatek: device tree docs for MTK Smart Device Gen1 NAND Jorge Ramirez-Ortiz
2016-03-08 15:00   ` Boris Brezillon
2016-03-08 18:19     ` Brian Norris
2016-03-08 15:15   ` Boris Brezillon
2016-03-02 17:00 ` [PATCH 2/3] mtd: mediatek: driver " Jorge Ramirez-Ortiz
2016-03-08 16:24   ` Boris Brezillon
2016-03-08 17:17     ` Jorge Ramirez-Ortiz
2016-03-08 18:17     ` Brian Norris
2016-03-08 20:08       ` Jorge Ramirez-Ortiz
2016-03-08 20:20         ` Brian Norris
2016-03-08 20:57           ` Jorge Ramirez-Ortiz
2016-03-08 21:22             ` Brian Norris
2016-03-08 22:02               ` Jorge Ramirez-Ortiz
2016-03-09 10:00             ` Boris Brezillon
2016-03-09 20:01     ` Jorge Ramirez-Ortiz
2016-03-09 20:43       ` Boris Brezillon
2016-03-18 14:00         ` Jorge Ramirez-Ortiz
2016-03-18 14:24           ` Boris Brezillon
2016-03-15 12:28     ` Jorge Ramirez-Ortiz
2016-03-15 12:59       ` Boris Brezillon
2016-03-15 13:21         ` Jorge Ramirez-Ortiz
2016-03-15 13:53           ` Boris Brezillon [this message]
2016-03-02 17:00 ` [PATCH 3/3] mtd: mediatek: device tree enable NAND in MTK's 2701 evb Jorge Ramirez-Ortiz

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=20160315145339.28d50175@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dwmw2@infradead.org \
    --cc=jorge.ramirez-ortiz@linaro.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh@kernel.org \
    --cc=xiaolei.li@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox