Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp458142ybi; Tue, 2 Jul 2019 23:27:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqzdvS+tHVPKoGQNPueUXU9O2cO5F5BPWuJUXO5OFXYrkSNfTn2TA4KbzwTaXiFkE9fLjbJF X-Received: by 2002:a63:607:: with SMTP id 7mr32297861pgg.240.1562135235659; Tue, 02 Jul 2019 23:27:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562135235; cv=none; d=google.com; s=arc-20160816; b=P8YLqpCQ2c0nd8y5/T5JC4nYIrAhQE5VuIZc9eZussZdcemIQBxisRVcsxTc1z/WbC IhZ/ufc92PpFio/gF8m8dcX/4GuuE+Ar6gaqb7ST5tP0xbPWw/CY2bnG24PSXUhbPDqQ Q6SvH1QphubekYdrjWYC2pqbt/QV1Dw+Wm3sbKxt1oQhRWFrx3yLIBfb7P3fBTdduABS SJaY6rNSV1L1JjvSr81Wl5TlMqTcG/gGm09r3yZ6YhWRfn963xOnobLLKsAsHS7GaU3L KD4TeZF7SUbVitPApSmG5iOy5tH7DkGKZetn05hnUB6NyJBezjf9b9YI8xKWtNF9VBTY 02Nw== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=DXTMWe5Bo7GLF44cuijoP9GXuS9OYuFRGrciUNl8Mgw=; b=hfVD87RtLZTUDunfYCbdCJu8iXHq5IbvJwXJxIedmxiiU5KHZZxCHH+FoahXbA8u2Z 4cePtBJMfJ7EEEh2fX27qR3vwn7oQTlMyxqiFTm6X95sFXvT8hbfU7VrVmdqlpb0eZI8 aI4RZS+6fkNA/Fq4Xshvu18eLBNjPwgD/+WCs3SltmantPwDBHpUTb1g1ffGF+UoKq7A RFRAdULuwEjofRcD5wO1GRuenvkLCAsohZvjmxiJxt20+QhO1a9D0JtwuHs5FiFZT2iJ Kgx+93G2PYe8YtMykJyVD+hhxSQAIHNiGgNZ0ZzQMyhaVyRslu/mT5jfG/FwB/E1z9kX Pm5g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g9si1349842plm.207.2019.07.02.23.27.00; Tue, 02 Jul 2019 23:27:15 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727108AbfGCGZu (ORCPT + 99 others); Wed, 3 Jul 2019 02:25:50 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:35188 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725927AbfGCGZu (ORCPT ); Wed, 3 Jul 2019 02:25:50 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 32AE027FD39; Wed, 3 Jul 2019 07:25:48 +0100 (BST) Date: Wed, 3 Jul 2019 08:25:44 +0200 From: Boris Brezillon To: Naga Sureshkumar Relli Cc: miquel.raynal@bootlin.com, helmut.grohne@intenta.de, richard@nod.at, dwmw2@infradead.org, computersforpeace@gmail.com, marek.vasut@gmail.com, vigneshr@ti.com, bbrezillon@kernel.org, yamada.masahiro@socionext.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [LINUX PATCH v17 2/2] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface Message-ID: <20190703082544.5b0ea566@collabora.com> In-Reply-To: <20190625044630.31717-2-naga.sureshkumar.relli@xilinx.com> References: <20190625044630.31717-1-naga.sureshkumar.relli@xilinx.com> <20190625044630.31717-2-naga.sureshkumar.relli@xilinx.com> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-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 Mon, 24 Jun 2019 22:46:30 -0600 Naga Sureshkumar Relli wrote: > + > +/** > + * pl353_nand_exec_op_cmd - Send command to NAND device > + * @chip: Pointer to the NAND chip info structure > + * @subop: Pointer to array of instructions > + * Return: Always return zero > + */ > +static int pl353_nand_exec_op_cmd(struct nand_chip *chip, > + const struct nand_subop *subop) > +{ > + struct mtd_info *mtd = nand_to_mtd(chip); > + const struct nand_op_instr *instr; > + struct pl353_nfc_op nfc_op = {}; > + struct pl353_nand_controller *xnfc = to_pl353_nand(chip); > + unsigned long cmd_phase_data = 0, end_cmd_valid = 0; > + unsigned long end_cmd; > + unsigned int op_id, len; > + bool reading; > + u32 cmdphase_addrflags; > + > + pl353_nfc_parse_instructions(chip, subop, &nfc_op); > + instr = nfc_op.data_instr; > + op_id = nfc_op.data_instr_idx; > + pl353_smc_clr_nand_int(); > + > + /* Get the command phase address */ > + if (nfc_op.cmnds[1] != 0) { > + if (nfc_op.cmnds[0] == NAND_CMD_SEQIN) > + end_cmd_valid = 0; > + else > + end_cmd_valid = 1; You're testing the opcode, again. As I said several times, the ->exec_op() implementation should be opcode agnostic, it should just try to match sequences of -- cycles. > + } > + > + end_cmd = nfc_op.cmnds[1]; > + > + /* > + * The SMC defines two phases of commands when transferring data to or > + * from NAND flash. > + * Command phase: Commands and optional address information are written > + * to the NAND flash.The command and address can be associated with > + * either a data phase operation to write to or read from the array, > + * or a status/ID register transfer. > + * Data phase: Data is either written to or read from the NAND flash. > + * This data can be either data transferred to or from the array, > + * or status/ID register information. > + */ > + cmdphase_addrflags = ((nfc_op.naddrs << ADDR_CYCLES_SHIFT) | > + (end_cmd_valid << END_CMD_VALID_SHIFT) | > + (COMMAND_PHASE) | > + (end_cmd << END_CMD_SHIFT) | > + (nfc_op.cmnds[0] << START_CMD_SHIFT)); > + > + /* Get the data phase address */ > + end_cmd_valid = 0; > + > + xnfc->dataphase_addrflags = ((0x0 << CLEAR_CS_SHIFT) | > + (end_cmd_valid << END_CMD_VALID_SHIFT) | > + (DATA_PHASE) | > + (end_cmd << END_CMD_SHIFT) | > + (0x0 << ECC_LAST_SHIFT)); > + > + /* Command phase AXI Read & Write */ > + if (nfc_op.naddrs >= 5) { > + if (mtd->writesize > PL353_NAND_ECC_SIZE) { > + cmd_phase_data = nfc_op.addrs; > + > + /* Another address cycle for devices > 128MiB */ > + if (chip->options & NAND_ROW_ADDR_3) { Clearly, none of this belongs in the ->exec_op() implementation. Looks like something related to page read... > + writel_relaxed(cmd_phase_data, > + xnfc->regs + cmdphase_addrflags); > + cmd_phase_data = nfc_op.addrs_56; > + } > + } > + } else { > + if (nfc_op.addrs != -1) { > + int column = nfc_op.addrs; > + > + /* > + * Change read/write column, read id etc > + * Adjust columns for 16 bit bus width > + */ > + if ((chip->options & NAND_BUSWIDTH_16) && > + (nfc_op.cmnds[0] == NAND_CMD_READ0 || > + nfc_op.cmnds[0] == NAND_CMD_SEQIN || > + nfc_op.cmnds[0] == NAND_CMD_RNDOUT || > + nfc_op.cmnds[0] == NAND_CMD_RNDIN)) { > + column >>= 1; And you keep testing opcodes here. Note that the address cycles should have been adjusted by core already when we have 16-bit accesses. > + } > + cmd_phase_data = column; > + } > + } > + > + writel_relaxed(cmd_phase_data, xnfc->regs + cmdphase_addrflags); > + if (!nfc_op.data_instr) { > + if (nfc_op.rdy_timeout_ms) { > + if (pl353_wait_for_dev_ready(chip)) > + return -ETIMEDOUT; > + } > + > + return 0; > + } > + > + reading = (nfc_op.data_instr->type == NAND_OP_DATA_IN_INSTR); > + if (!reading) { > + len = nand_subop_get_data_len(subop, op_id); > + pl353_nand_write_data_op(chip, instr->ctx.data.buf.out, > + len, instr->ctx.data.force_8bit); > + if (nfc_op.rdy_timeout_ms) { > + if (pl353_wait_for_dev_ready(chip)) > + return -ETIMEDOUT; > + } > + > + ndelay(nfc_op.rdy_delay_ns); > + } else { > + len = nand_subop_get_data_len(subop, op_id); > + ndelay(nfc_op.rdy_delay_ns); > + if (nfc_op.rdy_timeout_ms) { > + if (pl353_wait_for_dev_ready(chip)) > + return -ETIMEDOUT; > + } > + > + pl353_nand_read_data_op(chip, instr->ctx.data.buf.in, len, > + instr->ctx.data.force_8bit); > + } > + > + return 0; > +}