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
next prev parent reply other threads:[~2016-03-15 13:54 UTC|newest]
Thread overview: 26+ 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:00 ` Jorge Ramirez-Ortiz
[not found] ` <56EC09F5.5020704-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-03-18 14:24 ` Boris Brezillon
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 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.