Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1713090imm; Fri, 8 Jun 2018 23:42:41 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKUmsZQ7NoRpgEqaoa9amd2ip9rtbPqppuSaSTHvDxQpp3VWSrO1snB0Z7x4V3uKUUQ4Shw X-Received: by 2002:a62:9945:: with SMTP id d66-v6mr9087824pfe.192.1528526561353; Fri, 08 Jun 2018 23:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528526561; cv=none; d=google.com; s=arc-20160816; b=YiPDqhRr+XnUrNni4oyvoxDyC63Bw5FJVT1hxrL51F7fE7zjhgY/rOJJcRNh3Ip4t9 DuvQ38V1b2Egx5r56yxV6jhAPnrB2X9EnWJTIts+/r4YkMVuFolwEBscXeRr6nUkYjtY +Qc5I6QTkzHiljn1Y30XXlHr0DfI7KX4itIdNNs6eog0Vo7YdzAfK0ra9Jk55JUq0WMS j1FLVtGxBCpD45AlfhRbrojtbmaUes5vdEzsKQOsx8MoKU3lWFHDrY9g8VBY07ZDVTuJ 1dmYgy9q8BB7yVoUSzpovq+yIUPNkV5tl1McFwcP2JblENAlDs/iQOkWe/Ij9B+zDao5 bEqg== 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=OGJ2z5ajH1lOf9ajhmqcROLd594W2Vw3R20/TlJ7H9w=; b=fu38FnDu3wcBZyZ742PueLRNwUbOYR13JUE6XxfAEQwK+pm57OLW855bwM5DMMSOcc PRcOItAWU2aTSKDfhq73vL/qzmG6rDCfN33tYPNoQ5NrWh2thdX6hbeIXPDlbKhXGtp0 yq0XP085glb5cS+DqpOugEGbefdNeo1Bk38hghoa+N60OtWV1aeu7cM8aWVkYURgQokz JJgL2yA/DX5UiRM21ycuHC9b4/SN9XGMqFqbJwx9QFIMtpOorqcfVJag8l4BMqgAbJPO i1JG1AVI8UOd0thbwmj8fFQrgMcaAQNPRYFYAqJ9Ri3T6Po9d+l6mcRnPgDEljABZHeh yPpQ== 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 s3-v6si9247574plp.443.2018.06.08.23.42.26; Fri, 08 Jun 2018 23:42:41 -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 S1753164AbeFIGmC (ORCPT + 99 others); Sat, 9 Jun 2018 02:42:02 -0400 Received: from mail.bootlin.com ([62.4.15.54]:50576 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752272AbeFIGmA (ORCPT ); Sat, 9 Jun 2018 02:42:00 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id EE3ED20799; Sat, 9 Jun 2018 08:41:57 +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 (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 6419920702; Sat, 9 Jun 2018 08:41:57 +0200 (CEST) Date: Sat, 9 Jun 2018 08:41:57 +0200 From: Boris Brezillon To: Stefan Agner Cc: Dmitry Osipenko , dwmw2@infradead.org, computersforpeace@gmail.com, marek.vasut@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, thierry.reding@gmail.com, dev@lynxeye.de, miquel.raynal@bootlin.com, richard@nod.at, marcel@ziswiler.com, krzk@kernel.org, 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 Subject: Re: [PATCH v3 4/6] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver Message-ID: <20180609084157.0c2f12e6@bbrezillon> In-Reply-To: <792ee71847f6f4752b8bcba65d22bf81@agner.ch> References: <20180531221637.6017-1-stefan@agner.ch> <20180531221637.6017-5-stefan@agner.ch> <20180609075256.725354d6@bbrezillon> <792ee71847f6f4752b8bcba65d22bf81@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 Sat, 09 Jun 2018 08:23:51 +0200 Stefan Agner wrote: > On 09.06.2018 07:52, Boris Brezillon wrote: > > On Fri, 08 Jun 2018 23:51:01 +0200 > > Stefan Agner wrote: > > > > > >> > > >> > void tegra_nand_controller_reset(struct tegra_nand_controller *ctrl) > >> > { > >> > int err; > >> > > >> > disable_irq(ctrl->irq); > >> > > >> > err = reset_control_reset(ctrl->rst); > >> > if (err) { > >> > dev_err(ctrl->dev, "Failed to reset HW: %d\n", err); > >> > msleep(HW_TIMEOUT); > >> > } > >> > > >> > writel_relaxed(NAND_CMD_STATUS, ctrl->regs + HWSTATUS_CMD); > >> > writel_relaxed(HWSTATUS_MASK, ctrl->regs + HWSTATUS_MASK); > >> > writel_relaxed(INT_MASK, ctrl->regs + ISR); > >> > >> If we do a controller reset, there is much more state than that which > >> needs to be restored. A lot of it is not readily available currently > >> (timing, ECC settings...) > > > > This is actually a good test to detect what is not properly initialized > > by the driver. Timings should be configured correctly through > > ->setup_data_interface(). ECC engine should be disabled by default and > > only enabled when ->{read,write}_page() is called. > > > > Is setup_data_interface guaranteed to be called after a failed > ->exec_op()/{read,write}_page()? No. Maybe I misunderstood when tegra_nand_controller_reset() was supposed to be called. That's something I would call only once, early in the probe function, so that the controller is placed in a well-known state before we start using it. Definitely not something you should call after each error. > > >> > >> That seems a lot of work for a code path I do not intend to ever use :-) > >> > > > > Not so sure it's a lot of work. If ECC and timing settings are the > > only thing you need to initialize then it should work just fine. > > Try with a controller reset and you'll know if you miss something ;-). > > Currently the setting gets written directly to the registers. Only the > enable flag is set in the HW ECC {read,write}_page() functions. So I > will have to store the complete register in the chip structure and write > them on every {read,write}_page()? Well, your solution works as long as you only have one chip connected to the controller. What we usually set the ECC config in ->select_chip() (or at least make sure the current setting matches the one we expect) and then enable the engine in read/write_page() (as you seem to already do).