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 6D134C433F5 for ; Thu, 16 Dec 2021 16:41:03 +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:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc: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=hD/ealBEThhgsdS8w6ZmM2PZmiHAxJOsyCegS9L9lI8=; b=tbzk1abNCIRsOL v3DwmROqD2ePRE1QpQotUyiy8zq3DrNITPjKCr+2px6KfAjPluHuBPlKAHqJe6Yd7LQtoQ0grEEgP Vm3hItbOM0+Td0zDRrl9C868z71uqqMJy08V9x+aSKLKRIYUe8qggmdLB8ViRdR2wVflbt+9Wttvd od5eNT8VY+8sA33hfIvLj3MkvPlM6XUblp8kc1toP6n9udHqer4cwAWf4ZZFt8za/4Ru94BwcGCB9 FRRoYdjNOhQlZhbCuG+bsYd0qXit/7U1FEiLFv8d0vDYbCNyoI7hYpyaAokzJEhEY9+pgyWuLlkoR iRHFfDRzP2GROA3U3zsA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxtnq-006grg-IW; Thu, 16 Dec 2021 16:40:22 +0000 Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxtZn-006bRx-G7 for linux-mtd@lists.infradead.org; Thu, 16 Dec 2021 16:25:55 +0000 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id DC8921C0003; Thu, 16 Dec 2021 16:25:45 +0000 (UTC) Date: Thu, 16 Dec 2021 17:25:44 +0100 From: Miquel Raynal To: Pratyush Yadav Cc: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus , Michael Walle , , Michal Simek , Thomas Petazzoni , Rob Herring , , Mark Brown , Subject: Re: [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes Message-ID: <20211216172544.2005d96e@xps13> In-Reply-To: <20211214194431.4kpwfgvju6msh5d4@ti.com> References: <20211210201039.729961-1-miquel.raynal@bootlin.com> <20211210201039.729961-3-miquel.raynal@bootlin.com> <20211214194431.4kpwfgvju6msh5d4@ti.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (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-20211216_082551_881348_DBD254E0 X-CRM114-Status: GOOD ( 49.93 ) 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 SGVsbG8gUHJhdHl1c2gsCgpwLnlhZGF2QHRpLmNvbSB3cm90ZSBvbiBXZWQsIDE1IERlYyAyMDIx IDAxOjE0OjMzICswNTMwOgoKPiBIaSBNaXF1ZWwsCj4gCj4gT24gMTAvMTIvMjEgMDk6MTBQTSwg TWlxdWVsIFJheW5hbCB3cm90ZToKPiA+IERlc2NyaWJlIHR3byBuZXcgbWVtb3JpZXMgbW9kZXM6 Cj4gPiAtIEEgc3RhY2tlZCBtb2RlIHdoZW4gdGhlIGJ1cyBpcyBjb21tb24gYnV0IHRoZSBhZGRy ZXNzIHNwYWNlIGV4dGVuZGVkCj4gPiAgIHdpdGggYW4gYWRkaXRpbmFscyB3aXJlcy4KPiA+IC0g QSBwYXJhbGxlbCBtb2RlIHdpdGggcGFyYWxsZWwgYnVzc2VzIGFjY2Vzc2luZyBwYXJhbGxlbCBm bGFzaGVzIHdoZXJlCj4gPiAgIHRoZSBkYXRhIGlzIHNwcmVhZC4KPiA+IAo+ID4gU2lnbmVkLW9m Zi1ieTogTWlxdWVsIFJheW5hbCA8bWlxdWVsLnJheW5hbEBib290bGluLmNvbT4KPiA+IC0tLQo+ ID4gIC4uLi9iaW5kaW5ncy9zcGkvc3BpLXBlcmlwaGVyYWwtcHJvcHMueWFtbCAgICB8IDI5ICsr KysrKysrKysrKysrKysrKysKPiA+ICAxIGZpbGUgY2hhbmdlZCwgMjkgaW5zZXJ0aW9ucygrKQo+ ID4gCj4gPiBkaWZmIC0tZ2l0IGEvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3Nw aS9zcGktcGVyaXBoZXJhbC1wcm9wcy55YW1sIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp bmRpbmdzL3NwaS9zcGktcGVyaXBoZXJhbC1wcm9wcy55YW1sCj4gPiBpbmRleCA1ZGQyMDkyMDZl ODguLjQxOTRmZWU4ZjU1NiAxMDA2NDQKPiA+IC0tLSBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJl ZS9iaW5kaW5ncy9zcGkvc3BpLXBlcmlwaGVyYWwtcHJvcHMueWFtbAo+ID4gKysrIGIvRG9jdW1l bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3NwaS9zcGktcGVyaXBoZXJhbC1wcm9wcy55YW1s Cj4gPiBAQCAtODIsNiArODIsMzUgQEAgcHJvcGVydGllczoKPiA+ICAgICAgZGVzY3JpcHRpb246 Cj4gPiAgICAgICAgRGVsYXksIGluIG1pY3Jvc2Vjb25kcywgYWZ0ZXIgYSB3cml0ZSB0cmFuc2Zl ci4KPiA+ICAKPiA+ICsgIHN0YWNrZWQtbWVtb3JpZXM6Cj4gPiArICAgICRyZWY6IC9zY2hlbWFz L3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL3VpbnQ2NC1tYXRyaXggIAo+IAo+IFdoeSBtYXRyaXg/ IENhbid0IHlvdSB1c2UgYXJyYXkgaGVyZT8gU29ycnksIEkgYW0gbm90IG11Y2ggZmFtaWxpYXIg d2l0aCAKPiBKU09OIHNjaGVtYS4KClllcywgUm9iIGFsc28gb3BlbmVkIHRoZSBkaXNjdXNzaW9u LCBJJ3ZlIGFuc3dlcmVkIHRoZXJlIG9uIHRoaXMgcG9pbnQsCmJ1dCBJIGFncmVlLCB0aGlzIHNo b3VsZCBiZSBkZWZpbmUgYXMgYW4gYXJyYXksIGJ1dCB0aGUgY3VycmVudCB0b29saW5nCnJlZnVz ZWQgdG8gYWNjZXB0IHdoYXQgSSB3YW50ZWQgZnJvbSBhIGR0LXdyaXRpbmcgcG9pbnQgb2Ygdmll dy4gTW9yZQpvbiB0aGF0IG9uIHRoZSBkZWRpY2F0ZWQgdGhyZWFkLgoKPiA+ICsgICAgZGVzY3Jp cHRpb246IFNldmVyYWwgU1BJIG1lbW9yaWVzIGNhbiBiZSB3aXJlZCBpbiBzdGFja2VkIG1vZGUu Cj4gPiArICAgICAgVGhpcyBiYXNpY2FsbHkgbWVhbnMgdGhhdCBlaXRoZXIgYSBkZXZpY2UgZmVh dHVyZXMgc2V2ZXJhbCBjaGlwCj4gPiArICAgICAgc2VsZWN0cywgb3IgdGhhdCBkaWZmZXJlbnQg ZGV2aWNlcyBtdXN0IGJlIHNlZW4gYXMgYSBzaW5nbGUKPiA+ICsgICAgICBiaWdnZXIgY2hpcC4g VGhpcyBiYXNpY2FsbHkgZG91YmxlcyAob3IgbW9yZSkgdGhlIHRvdGFsIGFkZHJlc3MKPiA+ICsg ICAgICBzcGFjZSB3aXRoIG9ubHkgYSBzaW5nbGUgYWRkaXRpb25hbCB3aXJlLCB3aGlsZSBzdGls bCBuZWVkaW5nCj4gPiArICAgICAgdG8gcmVwZWF0IHRoZSBjb21tYW5kcyB3aGVuIGNyb3NzaW5n IGEgY2hpcCBib3VuZGFyeS4gVGhlIHNpemUgb2YKPiA+ICsgICAgICBlYWNoIGNoaXAgc2hvdWxk IGJlIHByb3ZpZGVkIGFzIG1lbWJlcnMgb2YgdGhlIGFycmF5Lgo+ID4gKyAgICBtaW5JdGVtczog Mgo+ID4gKyAgICBtYXhJdGVtczogMgo+ID4gKyAgICBpdGVtczoKPiA+ICsgICAgICBtYXhJdGVt czogMSAgCj4gCj4gVGhhbmtzLiBUaGlzIGxvb2tzIGJldHRlciB0byBtZS4KPiAKPiBCdXQgYmVm b3JlIHdlIGdvIGFoZWFkLCBJIHRoaW5rIHRoZXJlIGhhcyBiZWVuIHNvbWUgY29uZnVzaW9uIGFy b3VuZCAKPiB3aGF0IGV4YWN0bHkgeW91ciBwYXRjaGVzIGludGVuZCB0byBzdXBwb3J0LiBMZXQn cyBjbGVhciB0aGVtIHVwIGZpcnN0LiAKPiBXaGF0IHR5cGUgb2Ygc2V0dXAgZG8geW91IHdhbnQg dG8gc3VwcG9ydD8KCkJlZm9yZSBJIHRyeSB0byBjbGFyaWZ5IHlvdXIgcXVlc3Rpb25zIGJlbG93 LCB0aGUgc2V0dXAgdGhhdCBJIGhhdmUgaXM6CgpYaWxpbnggWnlucU1QIFFTUEkgY29udHJvbGxl ciArIDIgZmxhc2hlcy4KCldoYXQgSSB3YW50IHRvIGRlc2NyaWJlIGlzIHRoZSBzcGVjaWZpYyBo YW5kbGluZyBvZiB3aGF0IHRoZSBYaWxpbngKUVNQSSBjb250cm9sbGVyIGlzIGFibGUgdG8gZG8u IFRoaXMgY29udHJvbGxlciBoYXMgdHdvIG1vZGVzIHdoZW4gd2lyZWQKdG8gbW9yZSB0aGFuIG9u ZSBmbGFzaDoKLSBzdGFja2VkCi0gcGFyYWxsZWwKCkkgaGF2ZSBub3QgZW50ZXJlZCB0aGUgZG9j dW1lbnRhdGlvbiBub3IgdGhlIGNvZGUgaW4gZGV0YWlscyB5ZXQsIGJ1dCBJCmJlbGlldmUgdGhh dCBoYW5kbGluZyB0d28gZmxhc2hlcyBpbiB0aGUgc3RhY2tlZCBjb25maWd1cmF0aW9uLCBiZXNp ZGVzCmEgY291cGxlIG9mIHBvc3NpYmxlIG9wdGltaXphdGlvbnMgdGhhdCBhcmUgcG9zc2libGUg YnkgdGhlIGhhcmR3YXJlLAppcyBjbG9zZSB0byB3aGF0IGFueSBjb250cm9sbGVyIHdvdWxkIGRv LiBNYXliZSB0aGVyZSBpcyBvbmUgZGlmZmVyZW5jZQp0aG91Z2gsIHdoZW4gaW4gdGhlICJzdGFj a2VkIiBtb2RlLCB0aGlzIGNvbnRyb2xsZXIgdHJlYXRzIHRoZSB0d28KZmxhc2hlcyBhcyBhIHNp bmdsZSBvbmUsIHNvIHRoYXQgaXMgd2h5LCBpZiB3ZSB3YW50IHRvIHN1cHBvcnQgdGhpcwoiYWR2 YW5jZWQiIG1vZGUsIHdlICpuZWVkKiBhIHdheSB0byBrbm93IHRoYXQgdGhpcyBtb2RlIHNob3Vs ZCBiZSB1c2VkCmJlY2F1c2UgdGhlIGNvbnRyb2xsZXIgZXhwZWN0cyBhIHdpZGVyIHJhbmdlIG9m IGFkZHJlc3Nlcy4KCkFib3V0IHRoZSBwYXJhbGxlbCBjb25maWd1cmF0aW9uLCB0aGVyZSBpcyBh YnNvbHV0ZWx5IG5vIGRvdWJ0IHRoYXQgd2UKaGF2ZSBubyBvdGhlciBjaG9pY2UgdGhhbiBkZXNj cmliaW5nIGhvdyB0aGUgZGF0YSBpcyBzcHJlYWQgYWNyb3NzIHR3bwpkZXZpY2VzLiBXZSBkb24n dCByZWFsbHkgY2FyZSBhYm91dCB0aGUgbWFubmVyLCBidXQgdGhlIGNvbnRyb2xsZXIKbmVlZHMg dG8ga25vdyBob3cgdG8gYXNzZXJ0IHRoZSB0d28gQ1MgaW50ZXJuYWxseSBzbyB0aGlzIGRlZmlu aXRlbHkKc29tZXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgZGVzY3JpYmVkLgoKTm93IHRoZSBxdWVz dGlvbiB5b3UgbWlnaHQgYXNrIGlzLCB3aHkgZG8gd2UgZGVmaW5lIHRoZXNlIHByb3BlcnRpZXMg YXMKZmxhc2ggcHJvcGVydGllcyB0aGVuPyBBbmQgdGhpcyBpcyBhIHJlYWwgZ29vZCBxdWVzdGlv biwgSSB0aGluayBib3RoCmFjdHVhbGx5IHdvcmsgYXMgbG9uZyBhcyB3ZSBjb25zaWRlciB0aGF0 IHdlIGNhbiBvbmx5IGhhdmUgZWl0aGVyIGEKc3BpLW1lbW9yeSBvciBhbnkgb3RoZXIgdHlwZSBv ZiBkZXZpY2Ugb24gYSBzaW5nbGUgYnVzLCBidXQgbm90IGJvdGggYXQKdGhlIHNhbWUgdGltZS4g SW4gdjEgSSBwcm9wb3NlZCBhIGNvbnRyb2xsZXIgcHJvcGVydHkuIE1hcmsgcHJvcG9zZWQgdG8K c3dpdGNoIGZvciBhIGRldmljZSBwcm9wZXJ0eSB3aGljaCBJIGRpZCBpbiB2MiBvbndhcmQuCgo+ ICAgMS4gT25lIHNpbmdsZSBmbGFzaCBidXQgd2l0aCBtdWx0aXBsZSBkaWVzLCB3aXRoIGVhY2gg ZGllIHNpdHRpbmcgb24gYSAKPiAgICAgIGRpZmZlcmVudCBDUy4KClllcy4KCj4gICAyLiBUd28g KG9yIG1vcmUpIGlkZW50aWNhbCBidXQgaW5kZXBlbmRlbnQgZmxhc2ggbWVtb3JpZXMgdG8gYmUg Cj4gICAgICB0cmVhdGVkIGFzIG9uZS4KClllcy4KCj4gICAzLiBUd28gKG9yIG1vcmUpIGRpZmZl cmVudCBhbmQgaW5kZXBlbmRlbnQgZmxhc2ggbWVtb3JpZXMgdG8gYmUgCj4gICAgICB0cmVhdGVk IGFzIG9uZS4KCkkgZG9uJ3Qga25vdy4gTXkgZmlyc3QgcHJvcG9zYWwgZXhjbHVkZWQgdGhlc2Us IGJ1dCBJIGJlbGlldmUgd2UgY2FuCmhhbmRsZSB0aGVtIHdpdGggdGhlIGNoYW5nZSB5b3VyIHBy b3Bvc2VkICh0aGUgZGV2aWNlIHNpemUgYXMgcGFydCBvZgp0aGUgcHJvcGVydHkpLgoKPiBJbiBv dXIgZWFybGllciBleGNoYW5nZXMgeW91IHNhaWQgeW91IHdhbnQgdG8gc3VwcG9ydCAyLiBBbmQg d2hlbiBJIAo+IHdhbnRlZCB5b3UgdG8gYWNjb3VudCBmb3IgMyBhcyB3ZWxsIHlvdSBzYWlkIHdl IHNob3VsZCB1c2UgbXRkY29uY2F0IGZvciAKPiB0aGF0LgoKTm90IHRoYXQgd2Ugc2hvdWxkLCBi dXQgdGhhdCB3ZSBjb3VsZCBiZWNhdXNlIGZyb20gYSBjb3JlIHBlcnNwZWN0aXZlCml0J3Mgd2F5 IG1vcmUgY2hhbGxlbmdpbmcgdGhhbiBzdXBwb3J0aW5nIGlkZW50aWNhbCBkZXZpY2VzLiBCdXQg dGhlCmNvbnZlcnNhdGlvbiBkcmlmdGVkIGFib3V0IHRoZSBzb2Z0d2FyZSBiYWNrZW5kIHRoYXQg d2Ugc2hvdWxkIHVzZQpyYXRoZXIgdGhhbiBvbiB0aGUgYWN0dWFsIGRlc2NyaXB0aW9uLCBiZWNh dXNlIG10ZGNvbmNhdCBpcyBub3QgYQpmZWF0dXJlIHdoaWNoIGJlbmVmaXRzIGZyb20gYW55IGtp bmQgb2YgZGVzY3JpcHRpb24geWV0LCBzbyBldmVuIGlmIHdlCnVzZSBtdGRjb25jYXQgYXMgYmFj a2VkLCB3ZSB3aWxsIG5lZWQgc29tZSBraW5kIG9mIGRlc2NyaXB0aW9uIGhlcmUgYXMKd2VsbC4g U28sIGFzIEkgdG9sZCBwcmV2aW91c2x5LCBJIGFtIGZpbmUgY29uc2lkZXJpbmcgdGhlc2Ugc2V0 dXBzCmluIG15IHByb3Bvc2FsLCB0aGF0J3Mgd2h5IEkgdXBkYXRlZCBteSBwcm9wb3NhbCB0byBp bmNsdWRlIHRoZQpkZXZpY2VzIHNpemUsIGV2ZW4gdGhvdWdoIHRoYXQgaXMgd2F5IG91dCBvZiBz Y29wZSBjb21wYXJlZCB0byBteQppbml0aWFsIHRhcmdldC4KCkJ1dCBoZXJlIHdlIGFyZSB0YWxr aW5nIGFib3V0IGRyaXZlciBjb2RlLCB3aGljaCBoYXMgbm90aGluZyB0byBkbyB3aXRoCnRoZSBi aW5kaW5ncy4gSWYgd2UgZm9jdXMgb24gdGhlIGJpbmRpbmdzLCBJIGJlbGlldmUgdGhlIHNvbHV0 aW9uIHdpdGgKdGhlIHNpemVzIGNvdmVycyBhbGwgY2FzZXMuCgo+IFNvIG15IHF1ZXN0aW9uIGlz LCB3aHkgY2FuJ3Qgd2UgdXNlIG10ZGNvbmNhdCBmb3IgMiBhcyB3ZWxsLCBzaW5jZSAKPiBpdCBp cyBqdXN0IGEgc3BlY2lhbCBjYXNlIG9mIDM/IEFuZCBpZiB3ZSBhcmUgdXNpbmcgbXRkY29uY2F0 LCB0aGVuIHdoeSAKPiBkbyB3ZSBuZWVkIHRoaXMgYXQgYWxsPyBTaG91bGRuJ3QgeW91IHRoZW4g Y2hvb3NlIHRoZSBjaGlwIGF0IE1URCBsYXllciAKPiBhbmQgdXNlIHRoZSByZXNwZWN0aXZlIFNQ SSBkZXZpY2UgdG8gZ2V0IHRoZSBDUyB2YWx1ZSwgd2hpY2ggd291bGQgbWFrZSAKPiB0aGlzIHBy b3BlcnR5IHVzZWxlc3M/CgpSZWFzb24gMToKQXMgZGVwaWN0ZWQgYWJvdmUsIHdoaWxlIHRoZSBz dGFja2VkIG1vZGUgbWlnaHQgbW9yZSBvciBsZXNzCmZpdCB0aGUgbXRkY29uY2F0IGlkZWEsIGl0 IGlzIGFic29sdXRlbHkgbm90IHRoZSBjYXNlIGZvciB0aGUgcGFyYWxsZWwKbW9kZS4KClJlYXNv biAyOgptdGRjb25jYXQgaXMgYSBzb2Z0d2FyZSBiYWNrZW5kLiBIZXJlIHdlIGFyZSBkaXNjdXNz aW5nIGJpbmRpbmdzLgpObyBtYXR0ZXIgd2hhdCBiYWNrZWQgd2UgZmluYWxseSBwaWNrLCB0aGVy ZSB3aWxsIGJlIHRoZSBuZWVkIGZvciBhCnByb3BlciBkZXNjcmlwdGlvbiBhbmQgc28gZmFyIHRo ZXJlIGhhcyBiZWVuIG5vIGJpbmRpbmcgZm9yIG10ZGNvbmNhdAooZXZlbiB0aG91Z2ggSSB0cmll ZCB0byBwdXNoIGluIGZhdm9yIG9mIGl0IGEgd2hpbGUgYWdvIHdpdGhvdXQKc3VjY2VzcykuIFNv IG5vIG1hdHRlciB3aGF0IHNvZnR3YXJlIHNvbHV0aW9uIHdlIHdlIGFkb3B0LCB3ZQoqd2lsbCog bmVlZCBhbiB1cHN0cmVhbSBiaW5kaW5nIGRlc2NyaXB0aW9uIGF0IHNvbWUgcG9pbnQuIEJ1dApt dGRjb25jYXQgcmVhbGx5IG1lYW5zICJ0aGVyZSBhcmUgdHdvIGRldmljZXMgd2Ugd2FudCB0byBj b25zaWRlciBhcyBhCnNpbmdsZSIuIFdoaWxlIGhlcmUgdGhlIHBvaW50IGlzOiB3ZSBoYXZlIHR3 byBkZXZpY2VzIHRoYXQgZ2V0CmFic3RyYWN0ZWQgYnkgdGhlIGNvbnRyb2xsZXIsIGFuZCB3ZSBz dGlsbCBtdXN0IGRlc2NyaWJlIHRoYXQuCgo+IEkgY2FuIHNlZSB0aGlzIG1ha2luZyBzZW5zZSBm b3IgY2FzZSAxLiBGb3IgdGhhdCBjYXNlIHlvdSBzYWlkIHlvdSBkb24ndCAKPiBoYXZlIGFuIGV4 aXN0aW5nIGRhdGFzaGVldCBvciBkZXZpY2UgdG8gcHJvcG9zZS4gQW5kIGlmIHRoZXJlIGlzIG5v IHJlYWwgCj4gZGV2aWNlIGRvaW5nIGl0IEkgc2VlIGxpdHRsZSBwb2ludCBpbiBmaWd1cmluZyBv dXQgYSBiaW5kaW5nIGZvciBpdC4KClllcywgYmVjYXVzZSBzb21ld2hhdCB3ZSBmb2N1c2VkIHRo ZSBkZWJhdGUgb3ZlciB0aGUgZGV2aWNlcywgd2hpbGUgSQp3YXMgaW5pdGlhbGx5IHRhbGtpbmcg YWJvdXQgYSBjb250cm9sbGVyIGFic3RyYWN0aW9uLiBUaGVyZSBpcyAoYXQKbGVhc3QpIG9uZSBj b250cm9sbGVyIGRvaW5nIHN1Y2ggYWJzdHJhY3Rpb25zLCB0aGUgWGlsaW54IFp5bnFNUApnZW5l cmljIFFTUEkgY29udHJvbGxlciwgdGhlIHNwZWMgaXMgcHVibGljIChjaGFwdGVyIDI0KToKaHR0 cHM6Ly93d3cueGlsaW54LmNvbS9zdXBwb3J0L2RvY3VtZW50YXRpb24vdXNlcl9ndWlkZXMvdWcx MDg1LXp5bnEtdWx0cmFzY2FsZS10cm0ucGRmCgpJIGhvcGUgYWxsIHRoaXMgY2xhcmlmaWVzIHRo ZSBzaXR1YXRpb24hCgpDaGVlcnMsCk1pcXXDqGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eCBNVEQgZGlzY3Vzc2lvbiBtYWlsaW5n IGxpc3QKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1t dGQvCg== 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 743FAC433F5 for ; Thu, 16 Dec 2021 16:25:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239742AbhLPQZx convert rfc822-to-8bit (ORCPT ); Thu, 16 Dec 2021 11:25:53 -0500 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:52641 "EHLO relay5-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239747AbhLPQZu (ORCPT ); Thu, 16 Dec 2021 11:25:50 -0500 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id DC8921C0003; Thu, 16 Dec 2021 16:25:45 +0000 (UTC) Date: Thu, 16 Dec 2021 17:25:44 +0100 From: Miquel Raynal To: Pratyush Yadav Cc: Richard Weinberger , Vignesh Raghavendra , Tudor Ambarus , Michael Walle , , Michal Simek , Thomas Petazzoni , Rob Herring , , Mark Brown , Subject: Re: [PATCH v4 2/3] spi: dt-bindings: Describe stacked/parallel memories modes Message-ID: <20211216172544.2005d96e@xps13> In-Reply-To: <20211214194431.4kpwfgvju6msh5d4@ti.com> References: <20211210201039.729961-1-miquel.raynal@bootlin.com> <20211210201039.729961-3-miquel.raynal@bootlin.com> <20211214194431.4kpwfgvju6msh5d4@ti.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org Hello Pratyush, p.yadav@ti.com wrote on Wed, 15 Dec 2021 01:14:33 +0530: > Hi Miquel, > > On 10/12/21 09:10PM, Miquel Raynal wrote: > > Describe two new memories modes: > > - A stacked mode when the bus is common but the address space extended > > with an additinals wires. > > - A parallel mode with parallel busses accessing parallel flashes where > > the data is spread. > > > > Signed-off-by: Miquel Raynal > > --- > > .../bindings/spi/spi-peripheral-props.yaml | 29 +++++++++++++++++++ > > 1 file changed, 29 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > > index 5dd209206e88..4194fee8f556 100644 > > --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > > +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml > > @@ -82,6 +82,35 @@ properties: > > description: > > Delay, in microseconds, after a write transfer. > > > > + stacked-memories: > > + $ref: /schemas/types.yaml#/definitions/uint64-matrix > > Why matrix? Can't you use array here? Sorry, I am not much familiar with > JSON schema. Yes, Rob also opened the discussion, I've answered there on this point, but I agree, this should be define as an array, but the current tooling refused to accept what I wanted from a dt-writing point of view. More on that on the dedicated thread. > > + description: Several SPI memories can be wired in stacked mode. > > + This basically means that either a device features several chip > > + selects, or that different devices must be seen as a single > > + bigger chip. This basically doubles (or more) the total address > > + space with only a single additional wire, while still needing > > + to repeat the commands when crossing a chip boundary. The size of > > + each chip should be provided as members of the array. > > + minItems: 2 > > + maxItems: 2 > > + items: > > + maxItems: 1 > > Thanks. This looks better to me. > > But before we go ahead, I think there has been some confusion around > what exactly your patches intend to support. Let's clear them up first. > What type of setup do you want to support? Before I try to clarify your questions below, the setup that I have is: Xilinx ZynqMP QSPI controller + 2 flashes. What I want to describe is the specific handling of what the Xilinx QSPI controller is able to do. This controller has two modes when wired to more than one flash: - stacked - parallel I have not entered the documentation nor the code in details yet, but I believe that handling two flashes in the stacked configuration, besides a couple of possible optimizations that are possible by the hardware, is close to what any controller would do. Maybe there is one difference though, when in the "stacked" mode, this controller treats the two flashes as a single one, so that is why, if we want to support this "advanced" mode, we *need* a way to know that this mode should be used because the controller expects a wider range of addresses. About the parallel configuration, there is absolutely no doubt that we have no other choice than describing how the data is spread across two devices. We don't really care about the manner, but the controller needs to know how to assert the two CS internally so this definitely something that needs to be described. Now the question you might ask is, why do we define these properties as flash properties then? And this is a real good question, I think both actually work as long as we consider that we can only have either a spi-memory or any other type of device on a single bus, but not both at the same time. In v1 I proposed a controller property. Mark proposed to switch for a device property which I did in v2 onward. > 1. One single flash but with multiple dies, with each die sitting on a > different CS. Yes. > 2. Two (or more) identical but independent flash memories to be > treated as one. Yes. > 3. Two (or more) different and independent flash memories to be > treated as one. I don't know. My first proposal excluded these, but I believe we can handle them with the change your proposed (the device size as part of the property). > In our earlier exchanges you said you want to support 2. And when I > wanted you to account for 3 as well you said we should use mtdconcat for > that. Not that we should, but that we could because from a core perspective it's way more challenging than supporting identical devices. But the conversation drifted about the software backend that we should use rather than on the actual description, because mtdconcat is not a feature which benefits from any kind of description yet, so even if we use mtdconcat as backed, we will need some kind of description here as well. So, as I told previously, I am fine considering these setups in my proposal, that's why I updated my proposal to include the devices size, even though that is way out of scope compared to my initial target. But here we are talking about driver code, which has nothing to do with the bindings. If we focus on the bindings, I believe the solution with the sizes covers all cases. > So my question is, why can't we use mtdconcat for 2 as well, since > it is just a special case of 3? And if we are using mtdconcat, then why > do we need this at all? Shouldn't you then choose the chip at MTD layer > and use the respective SPI device to get the CS value, which would make > this property useless? Reason 1: As depicted above, while the stacked mode might more or less fit the mtdconcat idea, it is absolutely not the case for the parallel mode. Reason 2: mtdconcat is a software backend. Here we are discussing bindings. No matter what backed we finally pick, there will be the need for a proper description and so far there has been no binding for mtdconcat (even though I tried to push in favor of it a while ago without success). So no matter what software solution we we adopt, we *will* need an upstream binding description at some point. But mtdconcat really means "there are two devices we want to consider as a single". While here the point is: we have two devices that get abstracted by the controller, and we still must describe that. > I can see this making sense for case 1. For that case you said you don't > have an existing datasheet or device to propose. And if there is no real > device doing it I see little point in figuring out a binding for it. Yes, because somewhat we focused the debate over the devices, while I was initially talking about a controller abstraction. There is (at least) one controller doing such abstractions, the Xilinx ZynqMP generic QSPI controller, the spec is public (chapter 24): https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf I hope all this clarifies the situation! Cheers, Miquèl