Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2074049imm; Thu, 24 May 2018 05:25:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo/WUaeIPYhJ0NmtNWzxJSRVQlPIYdwqd3a6oweGwJ2Ut1zpuntFAAPK3ispcXaSeTrFrCX X-Received: by 2002:a63:7c01:: with SMTP id x1-v6mr5694671pgc.286.1527164756219; Thu, 24 May 2018 05:25:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527164756; cv=none; d=google.com; s=arc-20160816; b=fvwhw9wsIp1a34XotqjOj95XHuom7LwUeJykQUr6nZbXA3DTy86aurUBe64R9oldyO HZzfyclPfXsvYBteORDB4sAWvd8bgEC4ehzKqONyuMiqu+SKHg4QjtaLfxI9I7XlcRC4 1hu67rag8q537YL3jUaZNGcD0QKrYnTKbhUjbhojHHVRmSUumR9U7L7fUc9zlsv8twXs a72zVGPd/7Tdbis4oKmW0cTFmwAOxQ8E9AdD8NuBDmOw4nKA8QqCiCTTZuuCqfav9ouf eQCTdqjRAt30SOgliD2B+E2W2Ki2GXvfRrxS72n9ce+zap96j8M3jtpA6g4eJCfyKFqM G4Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=cj1sLdamFP+Cesq6mxsJ9gN+X5poQ1ICPc10pAffT8w=; b=LPYr+O+nQCWER9BFCz8eFQUFdVLLsjGBWid6Y6S8wVHSIsgsnY2SkW2g4hO0fzybWg u6YlATo24ADYjrUPMMn2PBhuWfBNV9hKLeB6Ls34yWo3T5Q609nvF4cUKE96D+2wjlLR GmOFd/vRjL3IOf0HfvbpAriyClp2WsCHFUzuWUZWU8bIB/EjAoCbzXgf0LYYJynFlN6A QM+TR3A4wrk4pghzEqMRVEe9UgbzLpn0mR8MYkQ1slWlIGjxGyNYDy/gVZ571o/xrZhw ylQ+BpUAoLkVAUk3Ue0t4S/W2+00rRkkaR144PHGXV2HAaTxtyXe533OqRooP9TkPuqk V4Dg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o12-v6si21338448pfd.199.2018.05.24.05.25.41; Thu, 24 May 2018 05:25:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S970122AbeEXMYF (ORCPT + 99 others); Thu, 24 May 2018 08:24:05 -0400 Received: from mail.bootlin.com ([62.4.15.54]:56377 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965995AbeEXMYC (ORCPT ); Thu, 24 May 2018 08:24:02 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 761E42071B; Thu, 24 May 2018 14:24:00 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (chios.esd.ece.ntua.gr [147.102.5.180]) by mail.bootlin.com (Postfix) with ESMTPSA id 82343206A0; Thu, 24 May 2018 14:23:58 +0200 (CEST) Date: Thu, 24 May 2018 14:23:56 +0200 From: Boris Brezillon To: Stefan Agner Cc: dwmw2@infradead.org, computersforpeace@gmail.com, marek.vasut@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, thierry.reding@gmail.com, mturquette@baylibre.com, sboyd@kernel.org, dev@lynxeye.de, miquel.raynal@bootlin.com, richard@nod.at, marcel@ziswiler.com, krzk@kernel.org, digetx@gmail.com, benjamin.lindqvist@endian.se, jonathanh@nvidia.com, pdeschrijver@nvidia.com, pgaikwad@nvidia.com, mirza.krak@gmail.com, linux-mtd@lists.infradead.org, linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver Message-ID: <20180524142356.0fc68797@bbrezillon> In-Reply-To: <7b3cc3991fb054130fd54c6fdfec5097@agner.ch> References: <86fdf19ec92b732709732fb60199f16488b4b727.1526990589.git.stefan@agner.ch> <20180523161810.0ed9fe80@bbrezillon> <2d8107f0e6568512d691e9ea25a1e4e5@agner.ch> <20180524105614.3c51736c@bbrezillon> <7b3cc3991fb054130fd54c6fdfec5097@agner.ch> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 May 2018 13:09:53 +0200 Stefan Agner wrote: > On 24.05.2018 10:56, Boris Brezillon wrote: > > On Thu, 24 May 2018 10:46:27 +0200 > > Stefan Agner wrote: > > > >> Hi Boris, > >> > >> Thanks for the initial review! One small question below: > >> > >> On 23.05.2018 16:18, Boris Brezillon wrote: > >> > Hi Stefan, > >> > > >> > On Tue, 22 May 2018 14:07:06 +0200 > >> > Stefan Agner wrote: > >> >> + > >> >> +struct tegra_nand { > >> >> + void __iomem *regs; > >> >> + struct clk *clk; > >> >> + struct gpio_desc *wp_gpio; > >> >> + > >> >> + struct nand_chip chip; > >> >> + struct device *dev; > >> >> + > >> >> + struct completion command_complete; > >> >> + struct completion dma_complete; > >> >> + bool last_read_error; > >> >> + > >> >> + dma_addr_t data_dma; > >> >> + void *data_buf; > >> >> + dma_addr_t oob_dma; > >> >> + void *oob_buf; > >> >> + > >> >> + int cur_chip; > >> >> +}; > >> > > >> > This struct should be split in 2 structures: one representing the NAND > >> > controller and one representing the NAND chip: > >> > > >> > struct tegra_nand_controller { > >> > struct nand_hw_control base; > >> > void __iomem *regs; > >> > struct clk *clk; > >> > struct device *dev; > >> > struct completion command_complete; > >> > struct completion dma_complete; > >> > bool last_read_error; > >> > int cur_chip; > >> > }; > >> > > >> > struct tegra_nand { > >> > struct nand_chip base; > >> > dma_addr_t data_dma; > >> > void *data_buf; > >> > dma_addr_t oob_dma; > >> > void *oob_buf; > >> > }; > >> > >> Is there a particular reason why you would leave DMA buffers in the chip > >> structure? It seems that is more a controller thing... > > > > The size of those buffers is likely to be device dependent, so if you > > have several NANDs connected to the controller, you'll either have to > > have one buffer at the controller level which is max(all-chip-buf-size) > > or a buffer per device. > > > > Also, do you really need these buffers? The core already provide some > > which are suitable for DMA (chip->oob_poi and chip->data_buf). > > > > Good question, I am not sure, that was existing code. > > Are you sure data_buf it is DMA capable? > > nand_scan_tail allocates with kmalloc: > > chip->data_buf = kmalloc(mtd->writesize + mtd->oobsize, GFP_KERNEL); Yes, kmalloc() allocates DMA-able buffers, so those are DMA-safe.