From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org by pdx-caf-mail.web.codeaurora.org (Dovecot) with LMTP id JN8aOvlgHludPwAAmS7hNA ; Mon, 11 Jun 2018 11:46:02 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id D160B607BB; Mon, 11 Jun 2018 11:46:01 +0000 (UTC) Authentication-Results: smtp.codeaurora.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iS9sR7BB" X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by smtp.codeaurora.org (Postfix) with ESMTP id 3A89C60541; Mon, 11 Jun 2018 11:46:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3A89C60541 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932953AbeFKLp7 (ORCPT + 21 others); Mon, 11 Jun 2018 07:45:59 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:54116 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932841AbeFKLp5 (ORCPT ); Mon, 11 Jun 2018 07:45:57 -0400 Received: by mail-wm0-f68.google.com with SMTP id x6-v6so14080691wmc.3; Mon, 11 Jun 2018 04:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=pJiiJaJ0fMzIMU5MQmU54+o3CsbHItHwbBoztdNortE=; b=iS9sR7BBFfjrhY3DdG15UK3IejpZ6s6lxmBDZHEpmcU6ruztu9ho5MnWHLxsF9zFK1 4EgyUJrB23136PGzIQ8BYzHb46vKs2vWn89M77oqIEreogaw93Lpf7TElrBLaEYM10C2 vbpgOXV85E5UO1Z+jKOr9yHE4uGwBUiO5dDxRijz4crNqhEQeYDKoyQddH93IwmBwH5z azx0hsXxH/EEdIiweSuZdW6ZIlQe6VNO+2jJyXwhIQeIquK6caI3pNZFIqX88uGmn+95 6OsckJesIPv/hQqWsIfWzHE+FHD2hF6RqWhzL06N4fdyid1N9twdjNjbXu+ufFpP4BT+ VmPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=pJiiJaJ0fMzIMU5MQmU54+o3CsbHItHwbBoztdNortE=; b=mTp38QxgobUUoBwFhwZvf2A+rXdYGExWwwr8qiBTVE9z293ClOek5RmbR/B7A3P8DO YCuVT6P4o+MvRz/jeqPP0M5Szqlahp5qBzSDEDXH4WDuBO/RCDQ9WtFWQrZWM2lo97oD GWUjjp3EMOsPBfAmN7tOBbLgBkCobVak2RCIAHaCyjzkHAQojkDivdGvFD+bL7+2wEUo Qvk8n1VZkhDzZtD0QskxsRv17pJ6upblSPGJKHw4toYVyPamU84kV78VoEhMJVGQJ96Y X1fQ23OWFWHfZ0qdKTM4aM928jo3PHyGIeUhRsvKGORzcuhFuOahka9UnIEsswXvP9MD KNcg== X-Gm-Message-State: APt69E3VWIBZZb/tIljwLjSg5orNlSOrMGoPAh2iwN7k0L/9dGf7XeQb geWRI8vETqxlIiB7wZZejfA= X-Google-Smtp-Source: ADUXVKK9DYrE5KUagQdo9ySsjQDYt7Q6HmcXoFY9Q0cHvf4zfzU1yxZP+rgbo+7iLv5y/HzwmgRNeA== X-Received: by 2002:a1c:150:: with SMTP id 77-v6mr8571966wmb.3.1528717555527; Mon, 11 Jun 2018 04:45:55 -0700 (PDT) Received: from dimapc.localnet ([109.252.55.168]) by smtp.gmail.com with ESMTPSA id h11-v6sm15296544wrs.85.2018.06.11.04.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 04:45:54 -0700 (PDT) From: Dmitry Osipenko To: Boris Brezillon Cc: Stefan Agner , 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 Date: Mon, 11 Jun 2018 14:45:45 +0300 Message-ID: <1862022.905gDpZtpO@dimapc> In-Reply-To: <20180610173202.680d2ee8@bbrezillon> References: <20180531221637.6017-1-stefan@agner.ch> <1868760.y7shk6NfjH@dimapc> <20180610173202.680d2ee8@bbrezillon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday, 10 June 2018 18:32:02 MSK Boris Brezillon wrote: > On Sun, 10 Jun 2018 18:00:06 +0300 > > Dmitry Osipenko wrote: > > > >> That seems a lot of work for a code path I do not intend to ever use > > > >> :-) > > > > > > > > Are you sure that resetting HW resets the timing and other registers > > > > configuration? Reset implementation is HW-specific, like for example > > > > in a > > > > case of a video decoder the registers state is re-intialized on HW > > > > reset, > > > > but registers configuration is untouched in a case of resetting GPU. > > > > I'd > > > > suggest to check whether NAND controller resetting affects the HW > > > > configuration. > > > > > > It seems all registers are set back to their documented reset value: > > > > > > [boot loader/ROM initialized values] > > > [ 1.270253] tegra-nand 70008000.nand: Tegra NAND controller register > > > dump > > > [ 1.277051] tegra-nand 70008000.nand: COMMAND: 0x66880104 > > > [ 1.282457] tegra-nand 70008000.nand: STATUS: 0x00000101 > > > [ 1.287763] tegra-nand 70008000.nand: ISR: 0x01000120 > > > [ 1.292818] tegra-nand 70008000.nand: IER: 0x00000000 > > > [ 1.297863] tegra-nand 70008000.nand: CONFIG: 0x00840000 > > > [ 1.303181] tegra-nand 70008000.nand: TIMING: 0x05040000 > > > [ 1.308486] tegra-nand 70008000.nand: TIMING2: 0x00000003 > > > [ 1.313897] tegra-nand 70008000.nand: CMD_REG1: 0x00000000 > > > [ 1.319377] tegra-nand 70008000.nand: CMD_REG2: 0x00000030 > > > [ 1.324868] tegra-nand 70008000.nand: ADDR_REG1: 0x03000000 > > > [ 1.330435] tegra-nand 70008000.nand: ADDR_REG2: 0x00000000 > > > [ 1.336011] tegra-nand 70008000.nand: DMA_MST_CTRL: 0x04100004 > > > [ 1.341838] tegra-nand 70008000.nand: DMA_CFG_A: 0x00000fff > > > [ 1.347415] tegra-nand 70008000.nand: DMA_CFG_B: 0x0000001b > > > [ 1.352991] tegra-nand 70008000.nand: FIFO_CTRL: 0x0000aa00 > > > [reset] > > > [ 1.358559] tegra-nand 70008000.nand: Tegra NAND controller register > > > dump > > > [ 1.365352] tegra-nand 70008000.nand: COMMAND: 0x00800004 > > > [ 1.370744] tegra-nand 70008000.nand: STATUS: 0x00000101 > > > [ 1.376060] tegra-nand 70008000.nand: ISR: 0x00000100 > > > [ 1.381105] tegra-nand 70008000.nand: IER: 0x00000000 > > > [ 1.386161] tegra-nand 70008000.nand: CONFIG: 0x10030000 > > > [ 1.391466] tegra-nand 70008000.nand: TIMING: 0x00000000 > > > [ 1.396782] tegra-nand 70008000.nand: TIMING2: 0x00000000 > > > [ 1.402174] tegra-nand 70008000.nand: CMD_REG1: 0x00000000 > > > [ 1.407664] tegra-nand 70008000.nand: CMD_REG2: 0x00000000 > > > [ 1.413156] tegra-nand 70008000.nand: ADDR_REG1: 0x00000000 > > > [ 1.418722] tegra-nand 70008000.nand: ADDR_REG2: 0x00000000 > > > [ 1.424297] tegra-nand 70008000.nand: DMA_MST_CTRL: 0x24000000 > > > [ 1.430123] tegra-nand 70008000.nand: DMA_CFG_A: 0x00000000 > > > [ 1.435698] tegra-nand 70008000.nand: DMA_CFG_B: 0x00000000 > > > [ 1.441264] tegra-nand 70008000.nand: FIFO_CTRL: 0x0000aa00 > > > > Alright, then indeed it's not really worth to bother with HW resetting > > here. Probably only a kernel module reload or a reboot will help if HW is > > hung. Maybe NAND controller / chip recovering is something that NAND core > > should be handling in a such case by providing a nand_controller_reset() > > hook? > I don't see what the core could do to help with that. We'd end up with > a new hook implemented by the controller that would be called by the > controller driver when it knows it's safe to reset the controller. So, > why bother exposing that in the core? Giving a driver more flexibility is always a good thing. I'm not really familiar with mtd/ and maybe indeed it doesn't make much sense to move HW resetting to NAND core, though it looked to me that it should be always safe for NAND core to initiate HW resetting after IO failure and hence would be cleaner and nicer to have a unified HW reset management rather than to have each driver to do its own thing.