Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2476631ybi; Mon, 17 Jun 2019 05:36:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqxcB/cLYq4vYdYuKjcuG4/JABGiMWnrjuJhi3bmd3mXIcaXiVKuFI3pQn5UDBbyp108l3pI X-Received: by 2002:a62:ac1a:: with SMTP id v26mr92489925pfe.184.1560774981848; Mon, 17 Jun 2019 05:36:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560774981; cv=none; d=google.com; s=arc-20160816; b=rm7rvjdg39HHoMJ0qVlIFeJtGQYSKUto9rsPpaueHu7hl77PimsCAN4ukdJ87etM3d DmGD0WWIfa4s/LiQj3fHjyg9zs6UGeUVJFErVFazhCDBbj9otKduODnGBVjiR+h71oDL H3NNQ54rWHTXgSnMxYaeyTeJErPJ9iEtLozuoGrIpuAyUK4nTc70a+CsuCKQUCd8sa3D KKrsZKz7inBFfXepftTPF9m8BPqmID6eMn52LgN2g7Sa8aXHxUIaZFtuKYkqgyLqsoeY QPpMKqF/6t9g8p2MQHFFeYT3/RqqauZrnguxtuxEkziDIwGNAwmIXyT6ySkoQJZi9NHg xNFA== 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=W9SQl48vxGNmbfU/xwXMpTEx6HL2cxCGHoI5e6Kvg/8=; b=I/8bGI/RSscimPk5CEt2N2JbV0Jefy4JQIbc+XMVYcZJbZOkeUDkSElZ2WNWh3XjZD +4klZY2hCHVSQ226/59TLg33udQ5Nx1mp+ifs28KxUFkRi0eca7Anl5B5g165Iqb1UO0 z9B41GGLDf5m3X82/CJ6qEJEpYOySyuxAF5icK0gV1kAUhmB0+t0YSdYWn4knOTslVUo sFNTpkBe+A4yBPUIY1U1vH/wtyyGdUY9GsoNYIVAHwoiBlMAM3G0yFideudDZhZiPJkF FdK16LlP7RitQflKxV8gfqTIBGp3sRUzwFmqQSt/0AWzUHtdp/c1GywdiUKGiOS6vLNx XBDg== 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 y16si10446698pfm.236.2019.06.17.05.36.06; Mon, 17 Jun 2019 05:36:21 -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 S1727846AbfFQMfZ convert rfc822-to-8bit (ORCPT + 99 others); Mon, 17 Jun 2019 08:35:25 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:39883 "EHLO relay12.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725962AbfFQMfZ (ORCPT ); Mon, 17 Jun 2019 08:35:25 -0400 Received: from xps13 (aaubervilliers-681-1-81-150.w90-88.abo.wanadoo.fr [90.88.23.150]) (Authenticated sender: miquel.raynal@bootlin.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id C29EB20000E; Mon, 17 Jun 2019 12:35:11 +0000 (UTC) Date: Mon, 17 Jun 2019 14:35:10 +0200 From: Miquel Raynal To: masonccyang@mxic.com.tw Cc: bbrezillon@kernel.org, broonie@kernel.org, christophe.kerello@st.com, computersforpeace@gmail.com, devicetree@vger.kernel.org, dwmw2@infradead.org, geert@linux-m68k.org, juliensu@mxic.com.tw, lee.jones@linaro.org, liang.yang@amlogic.com, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org, marcel.ziswiler@toradex.com, marek.vasut@gmail.com, mark.rutland@arm.com, paul.burton@mips.com, richard@nod.at, robh+dt@kernel.org, stefan@agner.ch, zhengxunli@mxic.com.tw Subject: Re: [PATCH v3 2/4] mtd: rawnand: Add Macronix MX25F0A NAND controller Message-ID: <20190617143510.4ded5728@xps13> In-Reply-To: References: <1555320234-15802-1-git-send-email-masonccyang@mxic.com.tw> <1555320234-15802-3-git-send-email-masonccyang@mxic.com.tw> <20190512151820.4f2dd9da@xps13> <20190520142333.390091d5@xps13> <20190527144250.71908bd9@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mason, masonccyang@mxic.com.tw wrote on Wed, 29 May 2019 11:12:08 +0800: > Hi Miquel, > > > > > > > > +static void mxic_nand_select_chip(struct nand_chip *chip, int > > > > chipnr) > > > > > > > > > > > > _select_target() is preferred now > > > > > > > > > > Do you mean I implement mxic_nand_select_target() to control #CS ? > > > > > > > > > > If so, I need to call mxic_nand_select_target( ) to control #CS ON > > > > > and then #CS OFF in _exec_op() due to nand_select_target() > > nand_base,c> > > > > > is still calling chip->legacy.select_chip ? > > > > > > > > You must forget about the ->select_chip() callback. Now it should be > > > > handled directly from the controller driver. Please have a look at > the > > > > commit pointed against the marvell_nand.c driver. > > > > > > I have no Marvell NFC datasheet and have one question. > > > > > > In marvell_nand.c, there is no xxx_deselect_target() or > > > something like that doing #CS OFF. > > > marvell_nfc_select_target() seems always to make one of chip or die > > > #CS keep low. > > > > > > Is it right ? > > > > Yes, AFAIR there is no "de-assert" mechanism in this controller. > > > > > > > > How to make all #CS keep high for NAND to enter > > > low-power standby mode if driver don't use "legacy.select_chip()" ? > > > > See commit 02b4a52604a4 ("mtd: rawnand: Make ->select_chip() optional > > when ->exec_op() is implemented") which states: > > > > "When [->select_chip() is] not implemented, the core is assuming > > the CS line is automatically asserted/deasserted by the driver > > ->exec_op() implementation." > > > > Of course, the above is right only when the controller driver supports > > the ->exec_op() interface. > > Currently, it seems that we will get the incorrect data and error > operation due to CS in error toggling if CS line is controlled in > ->exec_op(). Most of the chips today are CS-don't-care, which chip are you using? Is this behavior publicly documented? Is this LPM mode always activated? > i.e,. > > 1) In nand_onfi_detect() to call nand_exec_op() twice by > nand_read_param_page_op() and annd_read_data_op() > > 2) In nand_write_page_xxx to call nand_exec_op() many times by > nand_prog_page_begin_op(), nand_write_data_op() and > nand_prog_page_end_op(). > > > Should we consider to add a CS line controller in struct nand_controller > i.e,. > > struct nand_controller { > struct mutex lock; > const struct nand_controller_ops *ops; > + void (*select_chip)(struct nand_chip *chip, int cs); > }; > > to replace legacy.select_chip() ? > No, if really needed, we could add a "macro op done" flag in the nand operation structure. Thanks, Miquèl