Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1722299imm; Fri, 8 Jun 2018 23:56:29 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK9mBA1bIYB8Hcs5Srj+XDBuQm9WtRyVL3fwCtOON2LWC8j0OPlJG6TNQTYVwniSzu1/Km4 X-Received: by 2002:a17:902:2c83:: with SMTP id n3-v6mr9582095plb.211.1528527389217; Fri, 08 Jun 2018 23:56:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528527389; cv=none; d=google.com; s=arc-20160816; b=P2nhKV2uDKZ7cYBhh51XD1cba2vTMIK9ha020V40QlFH7viCz1OOu/XESLAqdpd+hY 7NOcv8uvO8kxZEC0LieJLPp+y9DaDH0hrEuHnAKOF+2sCJUO3nhXXaenxPpzoZaTOqAj MdEFuHkiywdbX/3tW8hBU2m+5mBU2cCUw2uqaQ3NR0y8X3x5CQcRqLJOhwWOXbXJXj8F l9hAjs/ZccxQMpr1TAkqiS9LgxhLzl8JJ3d5ayfJkAaKOaSYptK8E5SC08qy3MmHxOQY s3W0RRUWrrTjXDy2UEi3jSP0Nmsu/fBZgiWxzTbXHqLUIX7btKyHujsF1M2d5+h3vxh1 1TTA== 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=ZCJQb4i12h9jl86QPfwlVpyS6NUuAVL2XZhFvlVS6mw=; b=imRkcNPb95KB8UbMWwHQdvneH7f19KzfuMcRfD5D6kM36QwrQepaNVPBuTwlZL+131 mAEfih7SO/Pmzf4fuur210/Xn/AbnhxfAu4AynOHe/MXvJmIhoU5J69m6bqqZlOCobT7 qjUYfm7Zmt+9syFNQYd3ODqNwk7RfE5VdymGmkjzpwPC2csiIT4aOYYFLK5vsM9OhaQ+ 7WQRycLOISl1LkgMbnT0TCDDRL2ycKVQF4ZkGz5N2KsxdesdKEjp3ciD2CX5rZP024gG NIabkySrLbbpOXrnbX7/JeyweNl1o3hUHdhf70FopcxXtRpV6Onj8AcWJ/I7N5K/2P1L +T7w== 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.56.14; Fri, 08 Jun 2018 23:56:29 -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 S1753107AbeFIGzt (ORCPT + 99 others); Sat, 9 Jun 2018 02:55:49 -0400 Received: from mail.bootlin.com ([62.4.15.54]:50781 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752599AbeFIGzr (ORCPT ); Sat, 9 Jun 2018 02:55:47 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 12AC9207C0; Sat, 9 Jun 2018 08:55:45 +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 82AF220702; Sat, 9 Jun 2018 08:55:44 +0200 (CEST) Date: Sat, 9 Jun 2018 08:55:44 +0200 From: Boris Brezillon To: Stefan Agner Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, pgaikwad@nvidia.com, dev@lynxeye.de, mirza.krak@gmail.com, benjamin.lindqvist@endian.se, pdeschrijver@nvidia.com, miquel.raynal@bootlin.com, linux-kernel@vger.kernel.org, krzk@kernel.org, jonathanh@nvidia.com, marek.vasut@gmail.com, robh+dt@kernel.org, thierry.reding@gmail.com, marcel@ziswiler.com, richard@nod.at, linux-tegra@vger.kernel.org, linux-mtd@lists.infradead.org, Dmitry Osipenko , computersforpeace@gmail.com, dwmw2@infradead.org Subject: Re: [PATCH v3 4/6] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver Message-ID: <20180609085544.073d803d@bbrezillon> In-Reply-To: <20180609084615.6fba31ec@bbrezillon> References: <20180531221637.6017-1-stefan@agner.ch> <20180531221637.6017-5-stefan@agner.ch> <20180609075256.725354d6@bbrezillon> <792ee71847f6f4752b8bcba65d22bf81@agner.ch> <20180609084157.0c2f12e6@bbrezillon> <20180609084615.6fba31ec@bbrezillon> 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, 9 Jun 2018 08:46:15 +0200 Boris Brezillon wrote: > On Sat, 9 Jun 2018 08:41:57 +0200 > Boris Brezillon wrote: > > > 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. > > Note that if you really want to reset the controller after an error, > you should also iterate over all chips and call nand_reset() on them. And that's clearly not possible to call nand_reset() from ->exec_op(), otherwise you might recurse indefinitely in ->exec_op() if it keeps failing, because nand_reset() relies on ->exec_op() to reset the chip. So, as you said initially, not a good idea to reset the controller in this case. But maybe you can clear the interrupts, mask them and cancel the current operation (if any).