Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5050001imm; Tue, 12 Jun 2018 01:29:29 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJwnPenwsYBdqMCPif7R2n5zwFtSD20YPDNySVoRglAWZBxDsw9pISOTAiwgLCdYSNh+FaU X-Received: by 2002:a63:3201:: with SMTP id y1-v6mr2368800pgy.419.1528792169867; Tue, 12 Jun 2018 01:29:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528792169; cv=none; d=google.com; s=arc-20160816; b=yVLEI22p1FFu/tx8g8BkDCknMzR9Mu9tRIvMzrhEJaxnMrTDWI94D3gJXWz1QsXfRZ xkkMMwytKp0NUXO3cGPeGWSrvLDsB1M0Bh7lH1QOhta48zzBsaxJkUaHhjsJc4RpNN+5 xcaydWlbOIPgW0GW/LRZADUzzo0iFZtJibVo7dDJYyVzJiIWFi0+mz+RBFmHub4wmZT/ CN9eyStl7ZF+6X4fMOCxXTVKi+XU1buqcFOUQVJsy8lU3kQYYUcUgsloW9q5TJ4hhRzb fOXrDOAhcNeWpYvEZpZUBXl/Ov1TUT6cy4rI9i5z4SXUdf5k1eZnUNDO7RamvfabG57Z kaqw== 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=ZLja+wuc4BpsKMNgJa9IIdq2dPShS7KK+YxnBqjkmJI=; b=KzC5XrDdAxeQOaTIpKu/pKevkwlEfX45vRxY8tXHLAa25l4haUH/2zQ9MGgmGdVDQQ huw8cWaV7YVwcDKdIutRV4fdEEamcHBjLUD2ovRH5sUYwU+SpWbzVyEzl/fB1d4uidbE l1GN5klhRIQZEDjuIdbiQnkP8ox+yIlAgA1Zz0HkH2SKHkWD/q/whH5OSMx7fmEJgq77 H7kRVxO78wVFm/bp46w28jBk4hXpRiZjkPIr7aDBuywpiusi8l3R0IsNprbFNZ1bjM0/ Ivjr/gecgplNeiZMDt7IWA5EIBR1yDvCaTIn11d32EtcKrxbP2qkTzAOYSFAEKm6nhja St4Q== 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 q15-v6si332174pls.358.2018.06.12.01.28.45; Tue, 12 Jun 2018 01:29: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 S933609AbeFLI1k (ORCPT + 99 others); Tue, 12 Jun 2018 04:27:40 -0400 Received: from mail.bootlin.com ([62.4.15.54]:39309 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932803AbeFLI1h (ORCPT ); Tue, 12 Jun 2018 04:27:37 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 3C68D20981; Tue, 12 Jun 2018 10:27:35 +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 (AAubervilliers-681-1-37-30.w90-88.abo.wanadoo.fr [90.88.156.30]) by mail.bootlin.com (Postfix) with ESMTPSA id B38C120376; Tue, 12 Jun 2018 10:27:34 +0200 (CEST) Date: Tue, 12 Jun 2018 10:27:34 +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, gaireg@gaireg.de, linux-mtd@lists.infradead.org, linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 4/6] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver Message-ID: <20180612102734.0ea3bfa5@bbrezillon> In-Reply-To: References: <20180611205224.23340-1-stefan@agner.ch> <20180611205224.23340-5-stefan@agner.ch> <4258393.O1xtUOGbca@dimapc> 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 Tue, 12 Jun 2018 10:06:42 +0200 Stefan Agner wrote: > On 12.06.2018 02:03, Dmitry Osipenko wrote: > > On Monday, 11 June 2018 23:52:22 MSK Stefan Agner wrote: > >> Add support for the NAND flash controller found on NVIDIA > >> Tegra 2 SoCs. This implementation does not make use of the > >> command queue feature. Regular operations/data transfers are > >> done in PIO mode. Page read/writes with hardware ECC make > >> use of the DMA for data transfer. > >> > >> Signed-off-by: Lucas Stach > >> Signed-off-by: Stefan Agner > >> --- > >> MAINTAINERS | 7 + > >> drivers/mtd/nand/raw/Kconfig | 6 + > >> drivers/mtd/nand/raw/Makefile | 1 + > >> drivers/mtd/nand/raw/tegra_nand.c | 1248 +++++++++++++++++++++++++++++ > >> 4 files changed, 1262 insertions(+) > >> create mode 100644 drivers/mtd/nand/raw/tegra_nand.c > >> > [snip] > >> +static int tegra_nand_cmd(struct nand_chip *chip, > >> + const struct nand_subop *subop) > >> +{ > >> + const struct nand_op_instr *instr; > >> + const struct nand_op_instr *instr_data_in = NULL; > >> + struct tegra_nand_controller *ctrl = to_tegra_ctrl(chip->controller); > >> + unsigned int op_id, size = 0, offset = 0; > >> + bool first_cmd = true; > >> + u32 reg, cmd = 0; > >> + int ret; > >> + > >> + for (op_id = 0; op_id < subop->ninstrs; op_id++) { > >> + unsigned int naddrs, i; > >> + const u8 *addrs; > >> + u32 addr1 = 0, addr2 = 0; > >> + > >> + instr = &subop->instrs[op_id]; > >> + > >> + switch (instr->type) { > >> + case NAND_OP_CMD_INSTR: > >> + if (first_cmd) { > >> + cmd |= COMMAND_CLE; > >> + writel_relaxed(instr->ctx.cmd.opcode, > >> + ctrl->regs + CMD_REG1); > >> + } else { > >> + cmd |= COMMAND_SEC_CMD; > >> + writel_relaxed(instr->ctx.cmd.opcode, > >> + ctrl->regs + CMD_REG2); > >> + } > >> + first_cmd = false; > >> + break; > >> + case NAND_OP_ADDR_INSTR: > >> + offset = nand_subop_get_addr_start_off(subop, op_id); > >> + naddrs = nand_subop_get_num_addr_cyc(subop, op_id); > >> + addrs = &instr->ctx.addr.addrs[offset]; > >> + > >> + cmd |= COMMAND_ALE | COMMAND_ALE_SIZE(naddrs); > >> + for (i = 0; i < min_t(unsigned int, 4, naddrs); i++) > >> + addr1 |= *addrs++ << (BITS_PER_BYTE * i); > >> + naddrs -= i; > >> + for (i = 0; i < min_t(unsigned int, 4, naddrs); i++) > >> + addr2 |= *addrs++ << (BITS_PER_BYTE * i); > >> + writel_relaxed(addr1, ctrl->regs + ADDR_REG1); > >> + writel_relaxed(addr2, ctrl->regs + ADDR_REG2); > >> + break; > >> + > >> + case NAND_OP_DATA_IN_INSTR: > >> + size = nand_subop_get_data_len(subop, op_id); > >> + offset = nand_subop_get_data_start_off(subop, op_id); > >> + > >> + cmd |= COMMAND_TRANS_SIZE(size) | COMMAND_PIO | > >> + COMMAND_RX | COMMAND_A_VALID; > >> + > >> + instr_data_in = instr; > >> + break; > >> + > >> + case NAND_OP_DATA_OUT_INSTR: > >> + size = nand_subop_get_data_len(subop, op_id); > >> + offset = nand_subop_get_data_start_off(subop, op_id); > >> + > >> + cmd |= COMMAND_TRANS_SIZE(size) | COMMAND_PIO | > >> + COMMAND_TX | COMMAND_A_VALID; > >> + > >> + memcpy(®, instr->ctx.data.buf.out + offset, size); > >> + writel_relaxed(reg, ctrl->regs + RESP); > >> + > >> + break; > >> + case NAND_OP_WAITRDY_INSTR: > >> + cmd |= COMMAND_RBSY_CHK; > >> + break; > >> + > >> + } > >> + } > >> + > >> + cmd |= COMMAND_GO | COMMAND_CE(ctrl->cur_cs); > >> + writel_relaxed(cmd, ctrl->regs + COMMAND); > >> + ret = wait_for_completion_io_timeout(&ctrl->command_complete, > >> + msecs_to_jiffies(500)); > > > > It's not obvious to me whether _io_ variant is appropriate to use here, would > > be nice if somebody could clarify that. Maybe block/ already does the IO > > accounting itself and hence the IO time would be counted twice in that case. > > Good that you bring this up. > > I don't think that there is any higher layer which could take care of > accounting. Usually, with raw nand there is no block layer involved > anyway. > > In a quick test it seems that only when using wait_for_completion_io I/O > is properly accounted in the "wait" section of top. > > So far only a single driver (omap2) used the _io variant, but I think it > is the right thing to do! After all, it is I/O... > > Boris or any other MTD maintainer, any comment on this? Given this definition of io_schedule_timeout() [1] (which is used when you call wait_for_completion_io_timeout()), I'd say it's not useful to use the _io_ version, simply because MTD devs are not exposed as blk devices, and thus don't need the blk_schedule_flush_plug() that is done is io_schedule_prepare(). But that also means MTD I/Os are not accounted as I/Os :-(. Let's go for the non-io version for now, since all drivers except omap2 seem to use this function. [1]https://elixir.bootlin.com/linux/v4.17.1/source/kernel/sched/core.c#L5164