Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2183398ybd; Mon, 24 Jun 2019 02:08:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyhde3+SRf5cMcMR7L6Sy8GJLyIYAXNYoAUymNn7p/gAMN9fd463BfbdQSdZpSefT4xaNgr X-Received: by 2002:a17:90a:a410:: with SMTP id y16mr23815638pjp.62.1561367303570; Mon, 24 Jun 2019 02:08:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561367303; cv=none; d=google.com; s=arc-20160816; b=vtcmokJQZuYJblWt1lxJvHYMWyG0xRmu0LkbUWcRmE878Fy21BxZsASB5zc7WD1L7r HKpHU2jI4cmBMLkWxYvRfQQburtEaOf8QoribCsfiBO4xuUguMgHZsT3wK0iSficyqkE jmWet8JAa7kqUTqTFwOUXi0EZxMYl6GZsMzVciJTmaN0p4Sei/t8cJc2ql2NQxM/dq3V TWPZ4vSHMS4DLXY6UjJW14gsDL1jbN49eq8kSMon9n0AB22TdIdL/3kQ6H4FmymzSsx5 HHKClfPs/a1WWHSeks3p6b349t9TYMUyr1B4ucsdk9YemSeJSCDaoKWCYRay+TO9NmRS bFkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:from:message-id:mime-version:subject :cc:to:references:in-reply-to; bh=zVOlsNFsZcL1u+NwFtgsWYHqJ1eFV9KKsJm9/qluAbA=; b=nlMlnrbA6i/dp6x9v+6KU7EieeLmDzpq53rmAarLZfBumjVWoskZxS8V+VHLTzSMYp NPsBap8QPBIGa/0afZBcTpyIjZL3x+WaPcIinzg/oStkayEBWmJlarUt/koaxvIZG00T EzJturJq4Brv16pduxtGmWyVkTe8NVTZ2oIb0bQhwAb33PWnUoqHwKgKgWnjCupURUc2 cBMZ4OngmmBXTu4YZzIt85qGIXY0ITQR8FTLfXWl8KawUUDon3Vic3AQbONnqRRPH0pM 0Gde4u+WNPydaJwdOuvToHA1JGcu2rrfGAHLcYWst/HeseUzzG+YPwjuSEOcVAn4a0xl EWQg== 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 q2si10490911pjq.89.2019.06.24.02.08.06; Mon, 24 Jun 2019 02:08:23 -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 S1728256AbfFXJF0 (ORCPT + 99 others); Mon, 24 Jun 2019 05:05:26 -0400 Received: from twhmllg3.macronix.com ([122.147.135.201]:13719 "EHLO TWHMLLG3.macronix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbfFXJFZ (ORCPT ); Mon, 24 Jun 2019 05:05:25 -0400 Received: from twhfmlp1.macronix.com (twhfm1p1.macronix.com [172.17.20.91]) by TWHMLLG3.macronix.com with ESMTP id x5O95Gw0035152; Mon, 24 Jun 2019 17:05:16 +0800 (GMT-8) (envelope-from masonccyang@mxic.com.tw) Received: from MXML06C.mxic.com.tw (mxml06c.macronix.com [172.17.14.55]) by Forcepoint Email with ESMTP id 81A6019632B11D4E365C; Mon, 24 Jun 2019 17:05:16 +0800 (CST) In-Reply-To: <20190619100904.6b759377@xps13> 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> <20190617143510.4ded5728@xps13> <20190618081436.5d488320@collabora.com> <20190618092901.3bdd9f61@collabora.com> <20190619100904.6b759377@xps13> To: "Miquel Raynal" Cc: bbrezillon@kernel.org, "Boris Brezillon" , 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 MIME-Version: 1.0 X-KeepSent: FCBB8981:B840C87C-48258423:00311FA8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP4 SHF90 June 10, 2013 Message-ID: From: masonccyang@mxic.com.tw Date: Mon, 24 Jun 2019 17:05:16 +0800 X-MIMETrack: Serialize by Router on MXML06C/TAIWAN/MXIC(Release 9.0.1FP10 HF265|July 25, 2018) at 2019/06/24 PM 05:05:16, Serialize complete at 2019/06/24 PM 05:05:16 Content-Type: text/plain; charset="US-ASCII" X-MAIL: TWHMLLG3.macronix.com x5O95Gw0035152 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Miquel, > > > > > > > > > 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(). > > > > > > Oh, and please provide the modifications you added on top of this patch. > > > Right now we're speculating on what you've done which is definitely not > > > an efficient way to debug this sort of issues. > > > > We really need to see the datasheet of the NAND chip which has a > problem and how this LPM mode is advertized to understand what the > chip expects and eventually how to work-around it. > > > The patch is to add in beginning of ->exec_op() to control CS# low and > > before return from ->exec_op() to control CS# High. > > i.e,. > > static in mxic_nand_exec_op( ) > > { > > cs_to_low(); > > > > > > > > cs_to_high(); > > return; > > } > > > > But for nand_onfi_detect(), > > it calls nand_read_param_page_op() and then nand_read_data_op(). > > mxic_nand_exec_op() be called twice for nand_onfi_detect() > > Yes, this is expected and usually chips don't care. As I replied to Boris's email previously. I think I have fixed the problem and the root cause is the our NFC's TX FIFO counter do a unnecessary reset in CS control function. currently, doing CS# control in ->exec_op() is OK to me. In addition, by Jones's comments about MFD, I will re-submit this raw NAND ctlr driver instead of MFD and raw-nand. -----------------------------------------------------------------------> MFD is for registering child devices of chips which offer genuine cross-subsystem functionality. It is not designed for mode selecting, or as a place to shove shared code just because a better location doesn't appear to exist. ------------------------------------------------------------------------< thanks & best regards, Mason CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. ===================================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================