From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk0-x232.google.com ([2607:f8b0:400d:c09::232]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1afov9-0001QR-55 for linux-mtd@lists.infradead.org; Tue, 15 Mar 2016 13:22:00 +0000 Received: by mail-qk0-x232.google.com with SMTP id x1so6536137qkc.1 for ; Tue, 15 Mar 2016 06:21:38 -0700 (PDT) Subject: Re: [PATCH 2/3] mtd: mediatek: driver for MTK Smart Device Gen1 NAND To: Boris Brezillon References: <1456938013-8819-1-git-send-email-jorge.ramirez-ortiz@linaro.org> <1456938013-8819-3-git-send-email-jorge.ramirez-ortiz@linaro.org> <20160308172437.6eccce05@bbrezillon> <56E7FFF5.4000803@linaro.org> <20160315135936.1c924789@bbrezillon> Cc: dwmw2@infradead.org, computersforpeace@gmail.com, matthias.bgg@gmail.com, robh@kernel.org, daniel.thompson@linaro.org, xiaolei.li@mediatek.com, linux-mtd@lists.infradead.org From: Jorge Ramirez-Ortiz Message-ID: <56E80C5F.2020406@linaro.org> Date: Tue, 15 Mar 2016 09:21:35 -0400 MIME-Version: 1.0 In-Reply-To: <20160315135936.1c924789@bbrezillon> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 03/15/2016 08:59 AM, Boris Brezillon wrote: > On Tue, 15 Mar 2016 08:28:37 -0400 > Jorge Ramirez-Ortiz 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. > I'd really like to avoid adding more custom DMA mapping code and that > starts by creating an API that is generic enough to handle all NAND > controller driver cases. > ok.