Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1865149imm; Thu, 24 May 2018 01:58:18 -0700 (PDT) X-Google-Smtp-Source: AB8JxZplzB5WMX7KYayvJSRHKAEojzp1SOJpUywUVDGm9rlhO8Fq0NOd8uTsnLhCFGs7v3x6IJ87 X-Received: by 2002:a62:d6da:: with SMTP id a87-v6mr6385985pfl.200.1527152298744; Thu, 24 May 2018 01:58:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527152298; cv=none; d=google.com; s=arc-20160816; b=o9bUhIzEzaki9OgXW00nD+lE4Vm/5r0jqUlJfREN0cCT39pM5pS4ZcDL1y0fxSRt2/ VPwTeKK9yMlDhNe3B3xCXogOlRv+MVGDZFAKyVqiNdM/TTK/6+rcLVcd0IvkxhloHKqF 0a89SQxgyDfLVnwb/WkheKvA7uM8ZD+1a+g0cQ2nkRuAapSvH1BzkbAXdbIc44g5gVbN uN/Ay4nMzP8ElrfvRSJ7JN52oW5i1WgJ1Lr4Uje3FquDTxCPY3PiDcw5M6n5UluKY7mF FgDvzCxgFxJXksTMjW36pV4c24qaPtI5Z3qvb2ehiH2JEFUhs51mc6/Sufkm52bzyrL5 HHSQ== 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=fhlS71fDvFo9IcEuy4Q04zYue/FeO8GQpPlRb2q/BTc=; b=Gw309oS5D5jAUu/YiFBRqWPzX6CH68TYcmEiZlnkH3Es1fOIFwNDhVTRWl/Rx8ECFr UywImr1axv/ZzmRdCSHr/n5HMxnQzOosQrt+okEmZO3MCDj+zQH84hr0e4zI5UAMc8dj NJLNvgR9hJ+r5mFwgxVk45IIio5wQ17ViYS9JMQPEHBx9tJNKDV+fToPYXQVkIi7x3MF 8S63KML4VKsgwh3svlUFXHdSZsXbCUQWj+akoDhJ0LyKACN6t/jDnnuPWa4gLCkZrT5W GnXcOloQ885H4nAjpPLVng66LpV2diNMI2GA/yBz2gtSuzgOMIUupUSICKJiYvEsV1pk L8xw== 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 l61-v6si20210864plb.507.2018.05.24.01.58.04; Thu, 24 May 2018 01:58:18 -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 S965687AbeEXI5S (ORCPT + 99 others); Thu, 24 May 2018 04:57:18 -0400 Received: from mail.bootlin.com ([62.4.15.54]:45248 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965639AbeEXI5P (ORCPT ); Thu, 24 May 2018 04:57:15 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 8C80B207D2; Thu, 24 May 2018 10:57:13 +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 F0943207F0; Thu, 24 May 2018 10:56:17 +0200 (CEST) Date: Thu, 24 May 2018 10:56:14 +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: <20180524105614.3c51736c@bbrezillon> In-Reply-To: <2d8107f0e6568512d691e9ea25a1e4e5@agner.ch> References: <86fdf19ec92b732709732fb60199f16488b4b727.1526990589.git.stefan@agner.ch> <20180523161810.0ed9fe80@bbrezillon> <2d8107f0e6568512d691e9ea25a1e4e5@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 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). > > If I move them, then struct tegra_nand would be basically empty. Can I > just use struct nand_chip and have no driver specific chip abstraction? Sure.