Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934889AbdCJLAP (ORCPT ); Fri, 10 Mar 2017 06:00:15 -0500 Received: from conssluserg-05.nifty.com ([210.131.2.90]:40391 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934547AbdCJLAK (ORCPT ); Fri, 10 Mar 2017 06:00:10 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com v2AB04iK022660 X-Nifty-SrcIP: [209.85.161.181] MIME-Version: 1.0 In-Reply-To: <20161130091722.2e35f32a@bbrezillon> References: <1480183585-592-1-git-send-email-yamada.masahiro@socionext.com> <20161127160459.5894be93@bbrezillon> <20161130091722.2e35f32a@bbrezillon> From: Masahiro Yamada Date: Fri, 10 Mar 2017 20:00:03 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/39] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb To: Boris Brezillon Cc: linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, Linux Kernel Mailing List , Marek Vasut , Brian Norris , Richard Weinberger , David Woodhouse , Cyrille Pitchen , Rob Herring , Mark Rutland , Andy Shevchenko Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2559 Lines: 80 Hi Boris, I am almost getting v2 done, and now I am testing it. I am having one problem. Please teach me. 2016-11-30 17:17 GMT+09:00 Boris Brezillon : >> [2] >> Remove driver-internal bounce buffer. >> The current Denali driver allocate DMA_BIDIRECTIONAL buffer >> to use it as a driver-internal bounce buffer. >> >> The hardware transfer page data into the bounce buffer, >> then CPU copies from the bounce buffer to a given buf (and oob_poi). >> This is not efficient. >> >> So, I want to set NAND_USE_BOUNCE_BUFFER flag >> and do dma_map_single directly for a given buffer. > > Sounds good. Be careful though, when you use the generic bounce buffer > interface you might have to clear the page cache info (->pagebuf = -1). Instead of memcpy() of the whole page, I am trying to use dma_map_single() in ecc->read_page() / ecc->write_page(). This will allow direct transfer between the buffer and the device by DMA. But, this does not work for Denali if use_bufpoi is set in nand_do_read_ops(). In the following code in nand_scan_tail(), if (!(chip->options & NAND_OWN_BUFFERS)) { nbuf = kzalloc(sizeof(*nbuf) + mtd->writesize + mtd->oobsize * 3, GFP_KERNEL); if (!nbuf) return -ENOMEM; nbuf->ecccalc = (uint8_t *)(nbuf + 1); nbuf->ecccode = nbuf->ecccalc + mtd->oobsize; nbuf->databuf = nbuf->ecccode + mtd->oobsize; chip->buffers = nbuf; chip->buffers->databuf has no guarantee for DMA'able alignment. (actually it has unwanted offset 0xc because sizeof(*nbuf) == 0xc on 32bit systems) If we could change the code as follows, nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL); nbuf->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL); nbuf->databuf = kmalloc(mtd->writesize + mtd->oobsize, GFP_KERNEL); chip->buffers->databuf would have DMA'able alignment in most cases without NAND_OWN_BUFFERS. (but, I am not sure if this is a good idea) So, the idea of NAND_OWN_BUFFERS is that drivers should allocate own buffers if they need to perform DMA-mapping in read_page(), write_page(), right? However, "git grep NAND_OWN_BUFFERS" shows cafe_nand.c is the only driver that does so. On the other hand, "git grep dma_map_single" has more hits, i.e. some drivers perform dma_map_single() for read/write without NAND_OWN_BUFFERS. I have no idea how they are working. -- Best Regards Masahiro Yamada