Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2077181imm; Thu, 24 May 2018 05:28:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrxGBScU2BC51KdIl/DjKPHZ1UNDt/eVO7fi6K/3emKPEnSEjye20XbGsgWHeP54OL74OZL X-Received: by 2002:a62:415d:: with SMTP id o90-v6mr7185728pfa.140.1527164913518; Thu, 24 May 2018 05:28:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527164913; cv=none; d=google.com; s=arc-20160816; b=U3ZL4x1UWCziC3VWM8MBSdsp55gN0BPLu8rZbnOXaM99/e6OOUCd+6yh04AM+vB2Dt FaEULOduiDL/7lD2R5NVNGz5bez5GnkgasoK0p0djN7UaoYT6iokHLzGlDPjBnvasgqp N66m6WaixK/6YMCaD4pJ/CAGxw39Ia3K24UIdtOp5QE1RMO6dmZJuY1QYjsubTkaf3kQ NP9oIUG+QyLUdAywh7fp8T8LPcXU3a2MmziLMo22v0Lkxl9ktoIS+Bxg7yC2A/alzARY aijHTv/WNzSSjP0kmmbq7aCqxOt9y9UBncff8RV6vQ3dd0/e98M4l56RGiJM9AfbDXAU LBFQ== 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=QVLFUraX5yBck7y4xsfVWgB7YLn0sMlNgooAarh5sdc=; b=n+QTsNwF/G8aVTeWfjlgoGcHBHnEGMTSDN/+T8NxlgFNFhaGynGrSwd0eeclhMI77/ YGnFOeYaXx7Fo1JiF81C2ipJdVjP9kyvPd34oMPG4XxGdFiASx1HARthOurucuilwz9P u6cpGq58O1NrhTOdxSPcXWmVCW7CiezdH/8DnOBmMiyW58OtRZgCLSoAKk953McsymD3 RFEnJ+4MI7OmHv/itjY9mQkRPqmP0cz8Z+7ctOLKpjy6fTWtTwSCzqcuPgCuOEcNP0Oz gd2zUYedaga7iADKaJPBe7GF8rxcsgAo7alsqWximGua2bs3INjTI9vp2eEqQ3n8locN TF2A== 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 u198-v6si10384724pgc.460.2018.05.24.05.28.17; Thu, 24 May 2018 05:28:33 -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 S970098AbeEXM1y (ORCPT + 99 others); Thu, 24 May 2018 08:27:54 -0400 Received: from mail.bootlin.com ([62.4.15.54]:56812 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965933AbeEXM1v (ORCPT ); Thu, 24 May 2018 08:27:51 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 247F1207E2; Thu, 24 May 2018 14:27:50 +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, URIBL_BLOCKED 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 4A2CF207D2; Thu, 24 May 2018 14:27:38 +0200 (CEST) Date: Thu, 24 May 2018 14:27:36 +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: <20180524142736.2ef157fe@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); Also, you might want to set the NAND_USE_BOUNCE_BUFFER flag in chip->options, so that the core always pass DMA-able buffers to your ->read/write_page[_raw] function. [1]https://elixir.bootlin.com/linux/v4.17-rc6/source/include/linux/mtd/rawnand.h#L202