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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 42C2BC433FE for ; Thu, 25 Nov 2021 14:13:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=zLfRShYWffZDCh+1a5f20UGyhBGG5aEF2wzaQr6UFu8=; b=VYBB8bnyXqa/CV7MgRO3XjHqjf ISyhbV7DvEuvP3QxEUrhvHmSj2lkuuP2Yle/10kDfjQG+aLcaYszVrvCwwaAAObdx2U1rC8UZU5bn 2oEIP5JQaneETwflzvqvdUapxCxbh4s/84EQ7rXbA/l11Ipw3gqSxvA2nKD9uQMF2aqd3CijCzemV NQi7M5oYjib6KyxAORdezI8l9SCQ0mNlfq6s9c3ZETSjB+xtyUNp4ztKw6F2lBLHJgoTSkCaW0U5e rv2taUZM+BWeKg3ZwPNyh9PLTZBJEqJQoliFD/SG1A4QFlSu8AVujRgXcNm4yslRvI+P2+HV1Vvcx tIz2TpaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mqFTt-007mft-3Q; Thu, 25 Nov 2021 14:12:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mqFTp-007mew-C2 for linux-mtd@lists.infradead.org; Thu, 25 Nov 2021 14:12:07 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5C59B6101D; Thu, 25 Nov 2021 14:12:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1637849525; bh=yphTqVO3vqIdlcckcfNgEk3j7be4ZjIEdwtA7cNO2KQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=G+/EVsDX1YE+x5RZyYvp56vE/TUw9FqTrInQr8wHziyLIhto8jh0AdTu5hYoPDueU PfWs3p5bk1WgvVdvbEjv6Zgeg/7gkPVui9SG1sRrka1W/iMnC7J3AvazEnEQtnUWFy K/u3OvxuGcvYTX8PrIwaKQvNkvGxV8RFH4IrGDGycwXcI4wkpmR+lVagWTVcJrRIbP jZQEI8joAk3x7NlvcDmG0LKiQTtp3mXbYcFClr7S7XACjvmpeCp4I44udBkwuLthk+ mv7HcuEz5EAnfc7t70SgFSitJlUlDfesUY2TvdBESuqbEUFxck0++DdHo8/Hqu8557 AD7XRBbwny98A== Subject: Re: [PATCH 4/4] mtd: nand: omap2: Add support for NAND Controller on AM64 SoC To: Miquel Raynal Cc: richard@nod.at, vigneshr@ti.com, kishon@ti.com, nm@ti.com, tony@atomide.com, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20211123103609.14063-1-rogerq@kernel.org> <20211123103609.14063-5-rogerq@kernel.org> <20211124131552.6b9bc506@xps13> From: Roger Quadros Message-ID: Date: Thu, 25 Nov 2021 16:12:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211124131552.6b9bc506@xps13> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211125_061205_479449_1614F1E8 X-CRM114-Status: GOOD ( 43.54 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 SGkgTWlxdWVsLAoKT24gMjQvMTEvMjAyMSAxNDoxNSwgTWlxdWVsIFJheW5hbCB3cm90ZToKPiBI aSBSb2dlciwKPiAKPiByb2dlcnFAa2VybmVsLm9yZyB3cm90ZSBvbiBUdWUsIDIzIE5vdiAyMDIx IDEyOjM2OjA5ICswMjAwOgo+IAo+PiBBTTY0IFNvQyBoYXMgYW4gaXNzdWUgd2hpY2ggcHJldmVu dHMgcHJvcGVyIDgtYml0IGFuZCAxNi1iaXQKPj4gcmVhZHMgZnJvbSBHUE1DLiBXZSBhcmUgbGlt aXRlZCB0byBkbyAzMi1iaXQgcmVhZHMgb25seS4KPiAKPiBGaXJzdCwgdGhhbmtzIGZvciB0aGlz IHNlcmllcyEKCk5vIHByb2JsZW0uIEp1c3QgbXkgam9iIDopCgo+IAo+PiBGb3JjZSAzMi1iaXQg b25seSByZWFkcyBvbiBhZmZlY3RlZCBwbGF0Zm9ybXMuCj4+Cj4gCj4gUGxlYXNlIGNoYW5nZSB0 aGUgY29tbWl0IHRpdGxlIHByZWZpeCB0bzogIm10ZDogcmF3bmFuZDogb21hcDI6IiBpbgo+IHBh dGNoIDIsIDMsIDQuCgpPSy4KCj4gIAo+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBRdWFkcm9zIDxy b2dlcnFAa2VybmVsLm9yZz4KPj4gLS0tCj4+ICBkcml2ZXJzL210ZC9uYW5kL3Jhdy9vbWFwMi5j IHwgMzUgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKPj4gIDEgZmlsZSBjaGFu Z2VkLCAzNSBpbnNlcnRpb25zKCspCj4+Cj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL210ZC9uYW5k L3Jhdy9vbWFwMi5jIGIvZHJpdmVycy9tdGQvbmFuZC9yYXcvb21hcDIuYwo+PiBpbmRleCBmMWZj MTQ2ZTA5YjkuLmQ5NTJkZTc3MWIzNSAxMDA2NDQKPj4gLS0tIGEvZHJpdmVycy9tdGQvbmFuZC9y YXcvb21hcDIuYwo+PiArKysgYi9kcml2ZXJzL210ZC9uYW5kL3Jhdy9vbWFwMi5jCj4+IEBAIC0y OCw2ICsyOCw3IEBACj4+ICAKPj4gICNpbmNsdWRlIDxsaW51eC9vbWFwLWdwbWMuaD4KPj4gICNp bmNsdWRlIDxsaW51eC9wbGF0Zm9ybV9kYXRhL210ZC1uYW5kLW9tYXAyLmg+Cj4+ICsjaW5jbHVk ZSA8bGludXgvc3lzX3NvYy5oPgo+PiAgCj4+ICAjZGVmaW5lCURSSVZFUl9OQU1FCSJvbWFwMi1u YW5kIgo+PiAgI2RlZmluZQlPTUFQX05BTkRfVElNRU9VVF9NUwk1MDAwCj4+IEBAIC0xODEsNiAr MTgyLDcgQEAgc3RydWN0IG9tYXBfbmFuZF9pbmZvIHsKPj4gIAl2b2lkICgqZGF0YV9vdXQpKHN0 cnVjdCBuYW5kX2NoaXAgKmNoaXAsCj4+ICAJCQkgY29uc3Qgdm9pZCAqYnVmLCB1bnNpZ25lZCBp bnQgbGVuLAo+PiAgCQkJIGJvb2wgZm9yY2VfOGJpdCk7Cj4+ICsJYm9vbCBmb3JjZV8zMmJpdDsK PiAKPiBJIGJlbGlldmUgd2Ugc2hvdWxkIGhhdmUgYSBkcml2ZXIgY2FwYWJpbGl0eSBpbnN0ZWFk IG9mIHNvbWV0aGluZyBpbgo+IHRoZSBpbmZvIHN0cnVjdHVyZS4gWW91IGNhbiBzYXZlIHRoZSB2 YWx1ZSBoZXJlIGFzIHdlbGwgaW4gdGhlIHByb2JlIGlmCj4geW91IHdhbnQsIGJ1dCBJIHdvdWxk IGxpa2UgdGhpcyBsaW1pdGF0aW9uIHRvIGJlIHRpZWQgdG8gdGhlCj4gY29tcGF0aWJsZS4KCkkg d2lsbCBkaXNjdXNzIGFib3V0IHRoaXMgYXQgdGhlIGVuZC4KPiAKPj4gIH07Cj4+ICAKPj4gIHN0 YXRpYyBpbmxpbmUgc3RydWN0IG9tYXBfbmFuZF9pbmZvICptdGRfdG9fb21hcChzdHJ1Y3QgbXRk X2luZm8gKm10ZCkKPj4gQEAgLTIwNzAsNiArMjA3MiwyNSBAQCBzdGF0aWMgdm9pZCBvbWFwX25h bmRfZGF0YV9pbihzdHJ1Y3QgbmFuZF9jaGlwICpjaGlwLCB2b2lkICpidWYsCj4+ICAJc3RydWN0 IG9tYXBfbmFuZF9pbmZvICppbmZvID0gbXRkX3RvX29tYXAobmFuZF90b19tdGQoY2hpcCkpOwo+ PiAgCXUzMiBhbGlnbm1lbnQgPSAoKHVpbnRwdHJfdClidWYgfCBsZW4pICYgMzsKPj4gIAo+PiAr CWlmIChpbmZvLT5mb3JjZV8zMmJpdCkgewo+IAo+IEkgYW0gYSBsaXR0bGUgYml0IGJvdGhlcmVk IGJ5IHRoaXMgbGltaXRhdGlvbi4gVGhlIGZvcmNlOF9iaXQgZmxhZyBkb2VzCj4gbm90IHJlcXVp cmUgdGhlIGRyaXZlciB0byByZWFkIG9ubHkgOC1iaXRzIG9mIHRoZSBmaWZvIHJlZ2lzdGVyLCBp dAo+IGFjdHVhbGx5IHJlcXVpcmVzIHRvIHVzZSBvbmx5IHRoZSBmaXJzdCA4LWJpdHMgb2YgdGhl IE5BTkQgYnVzICh3aGljaAo+IGNhbiBhbHNvIGJlIDE2LWJpdCB3aWRlKS4gVGhlIG9sZGVyIGlt cGxlbWVudGF0aW9uIGp1c3QgbGltaXRlZCB0aGUKPiBudW1iZXIgb2YgYml0cyByZWFkcyB0byBi ZSA4IHdpdGggaW9yZWFkOCwgd2hpY2ggc2VlbXMgdG8gYmUgYSBmaW5lCj4gc29sdXRpb24gYnV0 IHdvdWxkIHJlcXVpcmUgbW9yZSBhY2Nlc3NlcyB0aGFuIHVzaW5nIGlvcmVhZDE2IChvcgo+IGlv cmVhZDMyKSB3aGVuIHJlYWRpbmcgbW9yZSB0aGFuIDEgYnl0ZSBvbiBwbGF0Zm9ybXMgd2l0aCBv bmx5IDgtYml0Cj4gYnVzc2VzLgoKSSBkaWRuJ3QgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiBm b3JjZThfYml0IGZsYWcuIApIb3cgc2hvdWxkIHRoZSBkcml2ZXIvY29udHJvbGxlciBiZWhhdmUg aWYgd2UgZ2V0IGEgZGF0YV9pbigpIGNhbGwgd2l0aCBsZW4gOCBhbmQgZm9yY2U4X2JpdCBmbGFn IHNldD8KCmUuZy4gaWYgMTYtYml0IE5BTkQgSUQgYXJlYSBjb250YWlucyAobGl0dGxlLWVuZGlh bikgMmMgZDMgZDAgYTYgNjYgNDUgNjcgYTMgNGYgNGUgNDYgNDkgYWIgZWYgOTAgZDMKd2hhdCBz aG91bGQgZGF0YV9pbihsZW4gPSA4LCBmb3JjZV84X2JpdCA9IDEpIHJldHVybiBpbiBidWZmZXI/ CgpCYXNlZCBvbiB3aGF0IHlvdSBzYWlkIGVhcmxpZXIgbXkgZ3Vlc3MgaXMgaXQgc2hvdWxkIHJl dHVybiAyYyBkMCA2NiA2NyA0ZiA0NiBhYiA5MD8KCj4gCj4gTXkgcG9pbnQgaGVyZSBpcyB0aGF0 Ogo+IDEtIHRoZSBsaW1pdGVkIGNvbnRyb2xsZXJzIGNhbm5vdCBiZSB1c2VkIHdpdGggYSAxNi1i aXQgYnVzCj4gMi0gbm9uLWxpbWl0ZWQgY29udHJvbGxlcnMgY2FuIHVzZSBpb3JlYWQxNiBpZiB0 aGUgYnVzIHdpZHRoIGlzIDgtYml0cwoKU29ycnksIEkgZGlkIG5vdCB1bmRlcnN0YW5kIHRoaXMg ZWl0aGVyLiBUaGUgVEkgR1BNQyBjb250cm9sbGVyIGhhcyBhIGNvbmZpZ3VyYXRpb24gc2V0dGlu ZyB3aGVyZSB3ZQpzZXQgdGhlIE5BTkQgZGV2aWNlIGJ1cyB3aWR0aCAoOC1iaXQgb3IgMTYtYml0 KS4gVGhlbiBpdCBhdXRvbWF0aWNhbGx5IGNvbnZlcnRzIGlvcmVhZDE2IG9yCmlvcmVhZDMyIHRv IGFwcHJvcHJpYXRlIG51bWJlciBvZiA4LWJpdCBhY2Nlc3NlcyBvciAxNi1iaXQgYWNjZXNzZXMg dG8gdGhlIE5BTkQgY2hpcC4KCj4gCj4gSSBndWVzcyBpdCdzIGZpbmUgbm90IHRvIGNoYW5nZSB0 aGUgbG9naWMgdG8gYXZvaWQgYnJlYWtpbmcgYm9hcmRzIHNvCj4gd2UgY2FuIGp1c3QgaWdub3Jl IFsyXSBidXQgSSBiZWxpdmUgd2Ugc2hvdWxkIGNoZWNrIGNoaXAtPm9wdGlvbnMgJgo+IE5BTkRf QlVTV0lEVEhfMTYgaW4gLT5hdHRhY2hfY2hpcCgpIGFuZCByZWZ1c2UgcHJvYmluZyBpZiB0aGlz IGZsYWcgaXMKPiBzZXQuCj4gCj4+ICsJCXUzMiB2YWw7Cj4+ICsJCWludCBsZWZ0Owo+PiArCQl1 OCAqcHRyOwo+PiArCj4+ICsJCWlvcmVhZDMyX3JlcChpbmZvLT5maWZvLCBidWYsIGxlbiA+PiAy KTsKPj4gKwkJbGVmdCA9IGxlbiAmIDB4MzsKPj4gKwkJaWYgKGxlZnQpIHsKPj4gKwkJCXZhbCA9 IGlvcmVhZDMyKGluZm8tPmZpZm8pOwo+PiArCQkJcHRyID0gKHU4ICopKGJ1ZiArIChsZW4gLSBs ZWZ0KSk7Cj4+ICsJCQl3aGlsZSAobGVmdC0tKSB7Cj4+ICsJCQkJKnB0cisrID0gdmFsICYgMHhm ZjsKPj4gKwkJCQl2YWwgPj49IDg7Cj4+ICsJCQl9Cj4+ICsJCX0KPj4gKwo+PiArCQlyZXR1cm47 Cj4+ICsJfQo+PiArCj4+ICAJaWYgKGZvcmNlXzhiaXQgfHwgKGFsaWdubWVudCAmIDEpKQo+PiAg CQlpb3JlYWQ4X3JlcChpbmZvLT5maWZvLCBidWYsIGxlbik7Cj4+ICAJZWxzZSBpZiAoYWxpZ25t ZW50ICYgMykKPj4gQEAgLTIxNjksOCArMjE5MCwxNSBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IG5h bmRfY29udHJvbGxlcl9vcHMgb21hcF9uYW5kX2NvbnRyb2xsZXJfb3BzID0gewo+PiAgc3RhdGlj IHN0cnVjdCBuYW5kX2NvbnRyb2xsZXIgb21hcF9ncG1jX2NvbnRyb2xsZXI7Cj4+ICBzdGF0aWMg Ym9vbCBvbWFwX2dwbWNfY29udHJvbGxlcl9pbml0aWFsaXplZDsKPj4gIAo+PiArc3RhdGljIGNv bnN0IHN0cnVjdCBvZl9kZXZpY2VfaWQgb21hcF9uYW5kX2lkc1tdOwo+PiArCj4gCj4gSSBiZWxp ZXZlIHRoaXMgY2hhbmdlIHNob3VsZCBiZSBkcm9wcGVkLgo+IAo+PiAgc3RhdGljIGludCBvbWFw X25hbmRfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKPj4gIHsKPj4gKwljb25z dCBzdHJ1Y3Qgc29jX2RldmljZV9hdHRyaWJ1dGUgazNfc29jX2RldmljZXNbXSA9IHsKPj4gKwkJ eyAuZmFtaWx5ID0gIkFNNjRYIiwgLnJldmlzaW9uID0gIlNSMS4wIiB9LAo+PiArCQl7IC8qIHNl bnRpbmVsICovIH0KPj4gKwl9Owo+PiArCj4+ICAJc3RydWN0IG9tYXBfbmFuZF9pbmZvCQkqaW5m bzsKPj4gIAlzdHJ1Y3QgbXRkX2luZm8JCQkqbXRkOwo+PiAgCXN0cnVjdCBuYW5kX2NoaXAJCSpu YW5kX2NoaXA7Cj4+IEBAIC0yMTg2LDYgKzIyMTQsMTIgQEAgc3RhdGljIGludCBvbWFwX25hbmRf cHJvYmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKPj4gIAo+PiAgCWluZm8tPnBkZXYg PSBwZGV2Owo+PiAgCj4+ICsJLyogU29tZSBTb0MncyBoYXZlIDMyLWJpdCBhdCBsZWFzdCwgcmVh ZCBsaW1pdGF0aW9uICovCj4+ICsJaWYgKHNvY19kZXZpY2VfbWF0Y2goazNfc29jX2RldmljZXMp KSB7Cj4+ICsJCWRldl9pbmZvKCZwZGV2LT5kZXYsICJmb3JjZSAzMi1iaXRcbiIpOwo+PiArCQlp bmZvLT5mb3JjZV8zMmJpdCA9IHRydWU7Cj4+ICsJfQo+PiArCj4gCj4gQXMgc3VnZ2VzdGVkIGFi b3ZlLCBqdXN0IGFkZGluZyBhIGNhcGFiaWxpdHkgc3RydWN0dXJlIHRpZWQgdG8gdGhlCj4gY29t cGF0aWJsZSBzdHJpbmcgYW5kIHJldHJpZXZlZCB3aXRoIG9mX2RldmljZV9nZXRfbWF0Y2hfZGF0 YSgpIHNob3VsZAo+IGJlIGVub3VnaCBhbmQgcmVwbGFjZSB0aGlzIG1hbnVhbCB0cmVlIHJlc2Vh cmNoLgoKVGhlIHRyb3VibGUgY29tZXMgd2hlbiBUSSB1cGRhdGVzIHRoZSBzaWxpY29uIHJldmlz aW9uIHRvICJTUjIuMCIgYW5kIHRoYXQgaGFzIHRoZSBpc3N1ZSBmaXhlZApidXQgc3RpbGwgdXNl cyB0aGUgc2FtZSBjb21wYXRpYmxlLiBTbyBjb21wYXRpYmxlIHN0cmluZyBieSBpdHNlbGYgaXMg bm90IHN1ZmZpY2llbnQgdG8gaWRlbnRpZnkKdGhlIHRyb3VibGVkIGRldmljZXMuIHNvY19kZXZp Y2VfbWF0Y2goKSB3YXMgdGhlIGVhc2llc3Qgd2F5IHRvIGFkZHJlc3MgdGhpcy4KCj4gCj4+ICAJ ZXJyID0gb21hcF9nZXRfZHRfaW5mbyhkZXYsIGluZm8pOwo+PiAgCWlmIChlcnIpCj4+ICAJCXJl dHVybiBlcnI7Cj4+IEBAIC0yMjg2LDYgKzIzMjAsNyBAQCBzdGF0aWMgaW50IG9tYXBfbmFuZF9y ZW1vdmUoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKPj4gIAo+PiAgc3RhdGljIGNvbnN0 IHN0cnVjdCBvZl9kZXZpY2VfaWQgb21hcF9uYW5kX2lkc1tdID0gewo+PiAgCXsgLmNvbXBhdGli bGUgPSAidGksb21hcDItbmFuZCIsIH0sCj4+ICsJeyAuY29tcGF0aWJsZSA9ICJ0aSxhbTY0LW5h bmQiLCB9LAo+PiAgCXt9LAo+PiAgfTsKPj4gIE1PRFVMRV9ERVZJQ0VfVEFCTEUob2YsIG9tYXBf bmFuZF9pZHMpOwo+IAo+IFRoZSBjb252ZXJzaW9uIHRvIGV4ZWNfb3AgbG9va3MgZmluZSBvdGhl cndpc2UgOikKClRoYW5rcyA6KQoKPiAKPiBUaGFua3MsCj4gTWlxdcOobAo+IAoKY2hlZXJzLAot cm9nZXIKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2273EC433F5 for ; Thu, 25 Nov 2021 14:14:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239907AbhKYORQ (ORCPT ); Thu, 25 Nov 2021 09:17:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:41028 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355618AbhKYOPQ (ORCPT ); Thu, 25 Nov 2021 09:15:16 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5C59B6101D; Thu, 25 Nov 2021 14:12:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1637849525; bh=yphTqVO3vqIdlcckcfNgEk3j7be4ZjIEdwtA7cNO2KQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=G+/EVsDX1YE+x5RZyYvp56vE/TUw9FqTrInQr8wHziyLIhto8jh0AdTu5hYoPDueU PfWs3p5bk1WgvVdvbEjv6Zgeg/7gkPVui9SG1sRrka1W/iMnC7J3AvazEnEQtnUWFy K/u3OvxuGcvYTX8PrIwaKQvNkvGxV8RFH4IrGDGycwXcI4wkpmR+lVagWTVcJrRIbP jZQEI8joAk3x7NlvcDmG0LKiQTtp3mXbYcFClr7S7XACjvmpeCp4I44udBkwuLthk+ mv7HcuEz5EAnfc7t70SgFSitJlUlDfesUY2TvdBESuqbEUFxck0++DdHo8/Hqu8557 AD7XRBbwny98A== Subject: Re: [PATCH 4/4] mtd: nand: omap2: Add support for NAND Controller on AM64 SoC To: Miquel Raynal Cc: richard@nod.at, vigneshr@ti.com, kishon@ti.com, nm@ti.com, tony@atomide.com, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20211123103609.14063-1-rogerq@kernel.org> <20211123103609.14063-5-rogerq@kernel.org> <20211124131552.6b9bc506@xps13> From: Roger Quadros Message-ID: Date: Thu, 25 Nov 2021 16:12:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211124131552.6b9bc506@xps13> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Miquel, On 24/11/2021 14:15, Miquel Raynal wrote: > Hi Roger, > > rogerq@kernel.org wrote on Tue, 23 Nov 2021 12:36:09 +0200: > >> AM64 SoC has an issue which prevents proper 8-bit and 16-bit >> reads from GPMC. We are limited to do 32-bit reads only. > > First, thanks for this series! No problem. Just my job :) > >> Force 32-bit only reads on affected platforms. >> > > Please change the commit title prefix to: "mtd: rawnand: omap2:" in > patch 2, 3, 4. OK. > >> Signed-off-by: Roger Quadros >> --- >> drivers/mtd/nand/raw/omap2.c | 35 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> >> diff --git a/drivers/mtd/nand/raw/omap2.c b/drivers/mtd/nand/raw/omap2.c >> index f1fc146e09b9..d952de771b35 100644 >> --- a/drivers/mtd/nand/raw/omap2.c >> +++ b/drivers/mtd/nand/raw/omap2.c >> @@ -28,6 +28,7 @@ >> >> #include >> #include >> +#include >> >> #define DRIVER_NAME "omap2-nand" >> #define OMAP_NAND_TIMEOUT_MS 5000 >> @@ -181,6 +182,7 @@ struct omap_nand_info { >> void (*data_out)(struct nand_chip *chip, >> const void *buf, unsigned int len, >> bool force_8bit); >> + bool force_32bit; > > I believe we should have a driver capability instead of something in > the info structure. You can save the value here as well in the probe if > you want, but I would like this limitation to be tied to the > compatible. I will discuss about this at the end. > >> }; >> >> static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd) >> @@ -2070,6 +2072,25 @@ static void omap_nand_data_in(struct nand_chip *chip, void *buf, >> struct omap_nand_info *info = mtd_to_omap(nand_to_mtd(chip)); >> u32 alignment = ((uintptr_t)buf | len) & 3; >> >> + if (info->force_32bit) { > > I am a little bit bothered by this limitation. The force8_bit flag does > not require the driver to read only 8-bits of the fifo register, it > actually requires to use only the first 8-bits of the NAND bus (which > can also be 16-bit wide). The older implementation just limited the > number of bits reads to be 8 with ioread8, which seems to be a fine > solution but would require more accesses than using ioread16 (or > ioread32) when reading more than 1 byte on platforms with only 8-bit > busses. I didn't understand the purpose of force8_bit flag. How should the driver/controller behave if we get a data_in() call with len 8 and force8_bit flag set? e.g. if 16-bit NAND ID area contains (little-endian) 2c d3 d0 a6 66 45 67 a3 4f 4e 46 49 ab ef 90 d3 what should data_in(len = 8, force_8_bit = 1) return in buffer? Based on what you said earlier my guess is it should return 2c d0 66 67 4f 46 ab 90? > > My point here is that: > 1- the limited controllers cannot be used with a 16-bit bus > 2- non-limited controllers can use ioread16 if the bus width is 8-bits Sorry, I did not understand this either. The TI GPMC controller has a configuration setting where we set the NAND device bus width (8-bit or 16-bit). Then it automatically converts ioread16 or ioread32 to appropriate number of 8-bit accesses or 16-bit accesses to the NAND chip. > > I guess it's fine not to change the logic to avoid breaking boards so > we can just ignore [2] but I belive we should check chip->options & > NAND_BUSWIDTH_16 in ->attach_chip() and refuse probing if this flag is > set. > >> + u32 val; >> + int left; >> + u8 *ptr; >> + >> + ioread32_rep(info->fifo, buf, len >> 2); >> + left = len & 0x3; >> + if (left) { >> + val = ioread32(info->fifo); >> + ptr = (u8 *)(buf + (len - left)); >> + while (left--) { >> + *ptr++ = val & 0xff; >> + val >>= 8; >> + } >> + } >> + >> + return; >> + } >> + >> if (force_8bit || (alignment & 1)) >> ioread8_rep(info->fifo, buf, len); >> else if (alignment & 3) >> @@ -2169,8 +2190,15 @@ static const struct nand_controller_ops omap_nand_controller_ops = { >> static struct nand_controller omap_gpmc_controller; >> static bool omap_gpmc_controller_initialized; >> >> +static const struct of_device_id omap_nand_ids[]; >> + > > I believe this change should be dropped. > >> static int omap_nand_probe(struct platform_device *pdev) >> { >> + const struct soc_device_attribute k3_soc_devices[] = { >> + { .family = "AM64X", .revision = "SR1.0" }, >> + { /* sentinel */ } >> + }; >> + >> struct omap_nand_info *info; >> struct mtd_info *mtd; >> struct nand_chip *nand_chip; >> @@ -2186,6 +2214,12 @@ static int omap_nand_probe(struct platform_device *pdev) >> >> info->pdev = pdev; >> >> + /* Some SoC's have 32-bit at least, read limitation */ >> + if (soc_device_match(k3_soc_devices)) { >> + dev_info(&pdev->dev, "force 32-bit\n"); >> + info->force_32bit = true; >> + } >> + > > As suggested above, just adding a capability structure tied to the > compatible string and retrieved with of_device_get_match_data() should > be enough and replace this manual tree research. The trouble comes when TI updates the silicon revision to "SR2.0" and that has the issue fixed but still uses the same compatible. So compatible string by itself is not sufficient to identify the troubled devices. soc_device_match() was the easiest way to address this. > >> err = omap_get_dt_info(dev, info); >> if (err) >> return err; >> @@ -2286,6 +2320,7 @@ static int omap_nand_remove(struct platform_device *pdev) >> >> static const struct of_device_id omap_nand_ids[] = { >> { .compatible = "ti,omap2-nand", }, >> + { .compatible = "ti,am64-nand", }, >> {}, >> }; >> MODULE_DEVICE_TABLE(of, omap_nand_ids); > > The conversion to exec_op looks fine otherwise :) Thanks :) > > Thanks, > Miquèl > cheers, -roger