From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEF8FC282C2 for ; Thu, 7 Feb 2019 13:01:52 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7D30B21904 for ; Thu, 7 Feb 2019 13:01:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JvI7kT3t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D30B21904 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=P8UcmmXREPf8MwqyB+JxeEi4DgrndKTRaLBd64kEszY=; b=JvI7kT3tIVlgWY 1+aWsLPc7/bN4Gcad9WdqXSdxDCIkpo+/iMbZj0wrm8kYf4FgMmT7VqXjEcYqhMa9JIPwm6imuzYi kYb7jMf7+1MGybuhzF6gpaQALlWl8H3CMl8jKH1ifxjm7q2vKTyrYB9/e46B7qW6UKTkxbFYLQHeo xhtoGXRCkm3/rjRVKMpjyDBzwRxp4cCKTJUScNh9MZkL2Hug+V3DzNuy8lrd7FKfBQ4Skq/MaULbG QvH4iCko8paz42S8GWjOXRtfwyNUz2LHaZv7E6/6yWmYK89Yxom7eZaKad4xQWsyUv5yCR/sQlW2b gfYmwTBJcNJMkPYNMyNg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1grjJN-0002Gh-NM; Thu, 07 Feb 2019 13:01:49 +0000 Received: from relay11.mail.gandi.net ([217.70.178.231]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1grjJJ-0002FY-Kv for linux-mtd@lists.infradead.org; Thu, 07 Feb 2019 13:01:47 +0000 Received: from xps13 (aaubervilliers-681-1-80-177.w90-88.abo.wanadoo.fr [90.88.22.177]) (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 587DC100002; Thu, 7 Feb 2019 13:01:36 +0000 (UTC) Date: Thu, 7 Feb 2019 14:01:36 +0100 From: Miquel Raynal To: Masahiro Yamada Subject: Re: [PATCH] mtd: rawnand: call onfi_fill_data_interface() once again after nand_detect Message-ID: <20190207140136.2ae62982@xps13> In-Reply-To: References: <1549533476-3742-1-git-send-email-yamada.masahiro@socionext.com> <20190207111606.6b72dc34@xps13> Organization: Bootlin X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190207_050145_988941_F5843B61 X-CRM114-Status: GOOD ( 26.43 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , Richard Weinberger , Boris Brezillon , Linux Kernel Mailing List , Boris Brezillon , linux-mtd , Brian Norris , David Woodhouse Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org SGkgTWFzYWhpcm8sCgpNYXNhaGlybyBZYW1hZGEgPHlhbWFkYS5tYXNhaGlyb0Bzb2Npb25leHQu Y29tPiB3cm90ZSBvbiBUaHUsIDcgRmViCjIwMTkgMTk6NDY6NTQgKzA5MDA6Cgo+IE9uIFRodSwg RmViIDcsIDIwMTkgYXQgNzoxNiBQTSBNaXF1ZWwgUmF5bmFsIDxtaXF1ZWwucmF5bmFsQGJvb3Rs aW4uY29tPiB3cm90ZToKPiA+Cj4gPiBIaSBNYXNhaGlybywKPiA+Cj4gPiBNYXNhaGlybyBZYW1h ZGEgPHlhbWFkYS5tYXNhaGlyb0Bzb2Npb25leHQuY29tPiB3cm90ZSBvbiBUaHUsICA3IEZlYgo+ ID4gMjAxOSAxODo1Nzo1NiArMDkwMDoKPiA+ICAKPiA+ID4gbmFuZF9zY2FuX2lkZW50KCkgY2Fs bHMgb25maV9maWxsX2RhdGFfaW50ZXJmYWNlKCkgYXQgaXRzIGVudHJ5Cj4gPiA+IHRvIHNldCB1 cCB0aGUgaW5pdGlhbCB0aW1pbmcgcGFyYW1ldGVycy4KPiA+ID4KPiA+ID4gVGhlIHRpbWluZyBw YXJhbWV0ZXJzIGFyZSBuZWVkZWQgbm90IG9ubHkgZm9yIC0+c2V0dXBfZGF0YV9pbnRlcmZhY2Uo KSwKPiA+ID4gYnV0IGFsc28gZm9yIGdpdmluZyB0aGUgY29ycmVjdCBkZWxheSB0byBOQU5EX09Q X1dBSVRfUkRZLCBmb3IgZXhhbXBsZS4KPiA+ID4KPiA+ID4gSWYgdGhlIGRyaXZlciBzZXRzIHRo ZSBOQU5EX0tFRVBfVElNSU5HUyBmbGFnLCBvciBkb2VzIG5vdCBzdXBwb3J0ICAKPiA+ID4gLT5z ZXR1cF9kYXRhX2ludGVyZmFjZSgpIGhvb2ssIHRob3NlIHBhcmFtZXRlcnMgd2lsbCBuZXZlciB1 cGRhdGVkLiAgCj4gPgo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXiBiZSAgCj4gCj4gV2lsbCBmaXggKGlmIHYyIGlzIHdlbGNv bWUpCj4gCj4gCj4gPiA+Cj4gPiA+IEJlZm9yZSBuYW5kX2RldGVjdCgpLCB3ZSBuZXZlciBrbm93 IHdoZXRoZXIgdGhlIGNoaXAgaXMgT05GaSBvciBub3QuCj4gPiA+IFNvLCBvbmZpX2ZpbGxfZGF0 YV9pbnRlcmZhY2UoKSBoYXMgdG8gYXNzdW1lIHRoZSB3b3JzdCBjYXNlLCBpLmUuCj4gPiA+IG5v bi1PTkZpLiAgCj4gPgo+ID4gcy9PTkZpL09ORkkvPyAgCj4gCj4gV2lsbCBmaXguCj4gCj4gTG9v a3MgbGlrZSBJIHdhcyBtaXN1bmRlcnN0YW5kaW5nCj4gbWF5YmUgYmVjYXVzZSB0aGUgbGV0dGVy ICdJJyBpbiB0aGUgbG9nbwo+IChodHRwOi8vd3d3Lm9uZmkub3JnLykKPiBsb29rcyBsaWtlIGEg bG93ZXJjYXNlLi4uCj4gCj4gCgpPaCByaWdodC4gSSBkb24ndCBrbm93IHdoYXQncyBiZXN0LiBQ aWNrIHlvdXIgZmF2b3JpdGUgOikKCj4gCj4gCj4gPiAgCj4gPiA+Cj4gPiA+IEFmdGVyIG5hbmRf ZGV0ZWN0KCksIGlmIHRoZSBjaGlwIHR1cm5zIG91dCB0byBiZSBPTkZpLWNvbXBsaWFudCwKPiA+ ID4gd2UgY2FuIG9wdGltaXplIHRQUk9HX21heCwgdEJFUlNfbWF4LCBldGMuCj4gPiA+Cj4gPiA+ IENhbGwgb25maV9maWxsX2RhdGFfaW50ZXJmYWNlKCkgb25jZSBhZ2Fpbi4gIAo+ID4KPiA+IFNv cnJ5IGJ1dCBJIGRvbid0IGdldCB3aHkgdGhpcyBpcyBuZWVkZWQgYXMgdGhlcmUgaXMgdGhlIHNh bWUgY2FsbCBhdAo+ID4gdGhlIHRvcCBvZiB0aGlzIGZ1bmN0aW9uLiBDYW4geW91IGJlIG1vcmUg c3BlY2lmaWMgb24gd2hlcmUvd2hlbiB0aGUKPiA+IG1pc3NpbmcgY2FsbCBwcm9kdWNlcyBhIGZh aWx1cmU/ICAKPiAKPiAKPiBvbmZpX2ZpbGxfZGF0YV9pbnRlcmZhY2UoKSBzZXRzIGRpZmZlcmVu dCB2YWx1ZXMKPiBmb3IgdFBST0dfbWF4LCB0QkVSX21heCwgdFJfbWF4LCB0Q0NTX21pbgo+IGRl cGVuZGluZyBvbiB3aGV0aGVyIHRoZSBjaGlwIGlzIE9ORkkgb3Igbm90Lgo+IAo+IEZvciB0aGUg Zmlyc3QgY2FsbCwgb25maV9maWxsX2RhdGFfaW50ZXJmYWNlKCkKPiBjaG9vc2VzIHRoZSBlbHNl LXBhcnQgc2luY2Ugd2UgbmV2ZXIga25vdwo+IHRoZSBjaGlwIHNwZWNpZmljYXRpb24gYXQgdGhp cyBwb2ludC4KPiAKPiBJZiB3ZSBjYWxsIG9uZmlfZmlsbF9kYXRhX2ludGVyZmFjZSgpIG9uY2Ug YWdhaW4KPiBhZnRlciBuYW5kX2RldGVjdCgpLCBpdCBtYXkgY2hvb3NlIHRoZSBpZi1wYXJ0Lgo+ IAo+IAo+IElmIGEgZHJpdmVyIHN1cHBvcnRzIC0+c2V0dXBfZGF0YV9pbnRlcmZhY2UoKSwKPiBu YW5kX2luaXRfZGF0YV9pbnRlcmZhY2UoKSB3aWxsIHNldCB0aGUgb3B0aW1hbAo+IHRpbWluZyBw YXJhbWV0ZXJzIGFueXdheS4KPiAKPiBCdXQsIGlmIGEgZHJpdmVyIGRvZXMgbm90IHN1cHBvcnQg LT5zZXR1cF9kYXRhX2ludGVyZmFjZSgpLAo+IGl0IHdpbGwgbm90IGhhcHBlbiBzaW5jZSBuYW5k X2hhc19zZXR1cF9kYXRhX2lmYWNlKCkgcmV0dXJucyBmYWxzZS4KCkFuZCBJIHRoaW5rIHRoaXMg aXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yLiBDYWxsaW5nIGFnYWluCm9uZmlfZmlsbF9kYXRhX2lu dGVyZmFjZSgpIHdvdWxkIHByb2JhYmx5IGVuaGFuY2UgYSBiaXQgdGhlIHRpbWluZ3MuClRoZSBl ZmZlY3QgaXMgdGhhdCBsYXRlciBleGNoYW5nZXMgd2l0aCB0aGUgTkFORCBjaGlwIHdvdWxkIGJl IGp1c3QgYQpiaXQgZmFzdGVyLiBCdXQgaWYgeW91IGNhcmUgYWJvdXQgcGVyZm9ybWFuY2UsIHRo ZW4gd2h5IG5vdCBpbXBsZW1lbnRpbmcKLT5zZXR1cF9kYXRhX2ludGVyZmFjZSgpPyBFdmVuIGEg ZHVtbXkgaW1wbGVtZW50YXRpb24gd291bGQgZG8gdGhlCnRyaWNrOiBvbmx5IGFjY2VwdCB0aW1p bmcgbW9kZSAwIHdpdGhvdXQgYW55IGNoYW5nZXMgb24gdGhlIGNvbnRyb2xsZXIKc2lkZS4KClVu bGVzcyB5b3UgZ2l2ZSBtZSBhIHVzZSBjYXNlIHdoZXJlIHRoaXMgaXMgbm90IHBvc3NpYmxlLCBJ IGRvbid0IHRoaW5rCml0IGlzIHdvcnRoIGNoYW5naW5nIHRoaXMgcGF0aC4KCgpUaGFua3MsCk1p cXXDqGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpMaW51eCBNVEQgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1tdGQvCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9BDFC282C2 for ; Thu, 7 Feb 2019 13:01:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A383521904 for ; Thu, 7 Feb 2019 13:01:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727347AbfBGNBl convert rfc822-to-8bit (ORCPT ); Thu, 7 Feb 2019 08:01:41 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:37423 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726894AbfBGNBk (ORCPT ); Thu, 7 Feb 2019 08:01:40 -0500 Received: from xps13 (aaubervilliers-681-1-80-177.w90-88.abo.wanadoo.fr [90.88.22.177]) (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 587DC100002; Thu, 7 Feb 2019 13:01:36 +0000 (UTC) Date: Thu, 7 Feb 2019 14:01:36 +0100 From: Miquel Raynal To: Masahiro Yamada Cc: linux-mtd , Boris Brezillon , Brian Norris , Linux Kernel Mailing List , Marek Vasut , Richard Weinberger , David Woodhouse , Boris Brezillon Subject: Re: [PATCH] mtd: rawnand: call onfi_fill_data_interface() once again after nand_detect Message-ID: <20190207140136.2ae62982@xps13> In-Reply-To: References: <1549533476-3742-1-git-send-email-yamada.masahiro@socionext.com> <20190207111606.6b72dc34@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 Masahiro, Masahiro Yamada wrote on Thu, 7 Feb 2019 19:46:54 +0900: > On Thu, Feb 7, 2019 at 7:16 PM Miquel Raynal wrote: > > > > Hi Masahiro, > > > > Masahiro Yamada wrote on Thu, 7 Feb > > 2019 18:57:56 +0900: > > > > > nand_scan_ident() calls onfi_fill_data_interface() at its entry > > > to set up the initial timing parameters. > > > > > > The timing parameters are needed not only for ->setup_data_interface(), > > > but also for giving the correct delay to NAND_OP_WAIT_RDY, for example. > > > > > > If the driver sets the NAND_KEEP_TIMINGS flag, or does not support > > > ->setup_data_interface() hook, those parameters will never updated. > > > > ^ be > > Will fix (if v2 is welcome) > > > > > > > > Before nand_detect(), we never know whether the chip is ONFi or not. > > > So, onfi_fill_data_interface() has to assume the worst case, i.e. > > > non-ONFi. > > > > s/ONFi/ONFI/? > > Will fix. > > Looks like I was misunderstanding > maybe because the letter 'I' in the logo > (http://www.onfi.org/) > looks like a lowercase... > > Oh right. I don't know what's best. Pick your favorite :) > > > > > > > > > > After nand_detect(), if the chip turns out to be ONFi-compliant, > > > we can optimize tPROG_max, tBERS_max, etc. > > > > > > Call onfi_fill_data_interface() once again. > > > > Sorry but I don't get why this is needed as there is the same call at > > the top of this function. Can you be more specific on where/when the > > missing call produces a failure? > > > onfi_fill_data_interface() sets different values > for tPROG_max, tBER_max, tR_max, tCCS_min > depending on whether the chip is ONFI or not. > > For the first call, onfi_fill_data_interface() > chooses the else-part since we never know > the chip specification at this point. > > If we call onfi_fill_data_interface() once again > after nand_detect(), it may choose the if-part. > > > If a driver supports ->setup_data_interface(), > nand_init_data_interface() will set the optimal > timing parameters anyway. > > But, if a driver does not support ->setup_data_interface(), > it will not happen since nand_has_setup_data_iface() returns false. And I think this is the expected behavior. Calling again onfi_fill_data_interface() would probably enhance a bit the timings. The effect is that later exchanges with the NAND chip would be just a bit faster. But if you care about performance, then why not implementing ->setup_data_interface()? Even a dummy implementation would do the trick: only accept timing mode 0 without any changes on the controller side. Unless you give me a use case where this is not possible, I don't think it is worth changing this path. Thanks, Miquèl