Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1680870imu; Tue, 6 Nov 2018 02:35:03 -0800 (PST) X-Google-Smtp-Source: AJdET5e5fFQI/xmYGarK2oNM1gTD0ayw19viumuGRvF3Z4vZfE7KhNOq1gCvQ5fW4hRSQbK8YtpS X-Received: by 2002:a17:902:684e:: with SMTP id f14-v6mr7441700pln.242.1541500503553; Tue, 06 Nov 2018 02:35:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541500503; cv=none; d=google.com; s=arc-20160816; b=dhg0oinck4z9s9REu0hgt3cFANHHC/VBIINq5zvuSvnOiYfoSrMiKCYIBX1A66Bhbs euD40WqSm3fOlgicSLFFBBZjWcXRuj7xp0kiiuhOQCIZPaPWxbYXDcMPS6g0aXofFixv V9bf+TsrRTKOH0xa4+V7DVQerfQ2sjnlX3DabRzyPOp3rkTue0sGdJchD2n+nxzylni5 Gl8yLUwy5q9zgD3Q8bwQn//M+9o011v35oWnG2IIxuqgaxtRjSnF7Z/rdckHC3Nw+FbV asgtGx4H7afMMO1FPyyMCLo+lFRFBP+OJjXVFKlt6KUw1BDOxkYWtxxIRXNKWr1GGvER sU2Q== 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; bh=H8dZbpWkLS9LoXmVKpQ9hhtQ7Gjw6YT65a0xlRzeHzg=; b=s1K1gaTDAKQukhaiWlXZZuzhRozovn9idreJfoofQwRumkhs/AuK9CBfD8Pctx/kbi s3TNQO1Z6m5kj6emttHoyoF6UDL25RITPZrSmGFNw4KLebehFGiWTsttdX6zdS99kkic gVJh2rggqEVCn7S0zKvD0H/7mzLaslsXAaGL6PoDwtfRHhdlF/8gq+0ZpR0xbjKi4ydN CLC/XwENHjYD9T6rFJo57dAV7BzCgwaZ5Pfg8SYSXi8IYt++6cBrYHiMXFuFpq97yuwf lrod2xPp9htMRa45aTCUofSDtBFOb7vL0lrZwgpCuPqmVYkxpw2PAQoumq8uAk2IQNMN xCQA== 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 f15-v6si40568990pgd.152.2018.11.06.02.34.48; Tue, 06 Nov 2018 02:35:03 -0800 (PST) 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 S2387854AbeKFTqp (ORCPT + 99 others); Tue, 6 Nov 2018 14:46:45 -0500 Received: from mail.bootlin.com ([62.4.15.54]:42747 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387480AbeKFTqp (ORCPT ); Tue, 6 Nov 2018 14:46:45 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id CB8CA207A3; Tue, 6 Nov 2018 11:22:12 +0100 (CET) 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-93-44.w90-88.abo.wanadoo.fr [90.88.34.44]) by mail.bootlin.com (Postfix) with ESMTPSA id 514992039F; Tue, 6 Nov 2018 11:22:12 +0100 (CET) Date: Tue, 6 Nov 2018 11:22:06 +0100 From: Boris Brezillon To: Liang Yang Cc: Jianxin Pan , , Yixun Lan , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Jerome Brunet , Neil Armstrong , Martin Blumenstingl , Carlo Caione , Kevin Hilman , Rob Herring , Jian Hu , Hanjie Lin , Victor Wan , , , Subject: Re: [PATCH v6 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller Message-ID: <20181106112206.65a70a81@bbrezillon> In-Reply-To: References: <1541090542-19618-1-git-send-email-jianxin.pan@amlogic.com> <1541090542-19618-3-git-send-email-jianxin.pan@amlogic.com> <20181105165321.7ea2b45f@bbrezillon> <20181106102851.61deb97a@bbrezillon> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; 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, 6 Nov 2018 18:00:37 +0800 Liang Yang wrote: > On 2018/11/6 17:28, Boris Brezillon wrote: > > On Tue, 6 Nov 2018 17:08:00 +0800 > > Liang Yang wrote: > > > >> On 2018/11/5 23:53, Boris Brezillon wrote: > >>> On Fri, 2 Nov 2018 00:42:21 +0800 > >>> Jianxin Pan wrote: > >>> > >>>> + > >>>> +static inline u8 meson_nfc_read_byte(struct mtd_info *mtd) > >>>> +{ > >>>> + struct nand_chip *nand = mtd_to_nand(mtd); > >>>> + struct meson_nfc *nfc = nand_get_controller_data(nand); > >>>> + u32 cmd; > >>>> + > >>>> + cmd = nfc->param.chip_select | NFC_CMD_DRD | 0; > >>>> + writel(cmd, nfc->reg_base + NFC_REG_CMD); > >>>> + > >>>> + meson_nfc_drain_cmd(nfc); > >>> > >>> You probably don't want to drain the FIFO every time you read a byte on > >>> the bus, and I guess the INPUT FIFO is at least as big as the CMD > >>> FIFO, right? If that's the case, you should queue as much DRD cmd as > >>> possible and only sync when the user explicitly requests it or when > >>> the INPUT/READ FIFO is full. > >>> > >> Register 'NFC_REG_BUF' can holds only 4 bytes, also DRD sends only one > >> nand cycle to read one byte and covers the 1st byte every time reading. > >> i think nfc controller is faster than nand cycle, but really it is not > >> high efficiency when reading so many bytes once. > >> Or use dma command here like read_page and read_page_raw. > > > > Yep, that's also an alternative, though you'll have to make sure the > > buffer passed through the nand_op_inst is DMA-safe, and use a bounce > > buffer when that's not the case. > > > ok, i will try dma here. We should probably expose the bounce buf handling as generic helpers at the rawnand level: void *nand_op_get_dma_safe_input_buf(struct nand_op_instr *instr) { void *buf; if (WARN_ON(instr->type != NAND_OP_DATA_IN_INSTR)) return NULL; if (virt_addr_valid(instr->data.in) && !object_is_on_stack(instr->data.buf.in)) return instr->data.buf.in; return kzalloc(instr->data.len, GFP_KERNEL); } void nand_op_put_dma_safe_input_buf(struct nand_op_instr *instr, void *buf) { if (WARN_ON(instr->type != NAND_OP_DATA_IN_INSTR) || WARN_ON(!buf)) return; if (buf == instr->data.buf.in) return; memcpy(instr->data.buf.in, buf, instr->data.len); kfree(buf); } const void *nand_op_get_dma_safe_output_buf(struct nand_op_instr *instr) { void *buf; if (WARN_ON(instr->type != NAND_OP_DATA_OUT_INSTR)) return NULL; if (virt_addr_valid(instr->data.out) && !object_is_on_stack(instr->data.buf.out)) return instr->data.buf.out; return kmemdup(instr->data.buf.out, GFP_KERNEL); } void nand_op_put_dma_safe_output_buf(struct nand_op_instr *instr, void *buf) { if (WARN_ON(instr->type != NAND_OP_DATA_OUT_INSTR) || WARN_ON(!buf)) return; if (buf != instr->data.buf.out) kfree(buf); } > > > > Isn't the controller engine able to wait on the data transfer to be > > complete before sending the next instruction in the CMD FIFO pipe? > > I'm pretty sure it's able to do that, which would make > > meson_nfc_wait_dma_finish() useless, and all you'd have to do is wait > > for the CMD FIFO to be empty (assuming it guarantees the last command > > has been executed). > > Maybe the nfc design is difference. dedicated nfc dma engine is > concatenated with the command fifo, there is no other status to check > whether dma is done. No, I mean that internally a "DMA-transfer" instruction probably forces the NAND controller to wait for the DMA transfer to be finished before dequeuing/executing the next instruction. So, it should be safe to queue the PROG and WAIT_RB instructions and just rely on the "FIFO empty" event to consider the operation as finished. Then, all you'll have to do is check the status reg to determine whether the write operation succeeded or not.