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 3F6A4CCF9E0 for ; Tue, 28 Oct 2025 15:42:11 +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:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HX9GdOA8wkiuqWHPWEr9CtU4C47WxRtAdtc2JPQkWMQ=; b=aMAR5vaYPB/Fhw +iaSojDZXahBNZ+qV3LWuAumR0GGxMbKqZzI9XraaPGFepa1BCpuW2rGeMkRlCYeSe2OHsQSxS+qN Vf5KSKW6g0EOAducxivAyK/v2HU08uQ/jcuPHlnFFZ1ESkD5aNSUZ5O8aS8VRMCu2AU21A3EbkmmU i64FN6Afu34/y9KsH7xu0vMNdjp8QK/Im+AXj5rHcFOUfoBXd+6LfLIT7bQqbv9jtmfAsVhJWnZGd hfWP8schvUgkTGWQH6EuNNEVzRX41Krd8b0olaxmpvOq2OyVdSbqyL+lS5JPcktJ3iEm0Vtar4kqT X3IdmWzNGFs5A2XKqv7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vDlpo-0000000GCdV-45J7; Tue, 28 Oct 2025 15:42:08 +0000 Received: from smtpout-03.galae.net ([185.246.85.4]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vDlpl-0000000GCbp-0nQl for linux-mtd@lists.infradead.org; Tue, 28 Oct 2025 15:42:07 +0000 Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 7B7D94E41397; Tue, 28 Oct 2025 15:42:01 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 44E7B606AB; Tue, 28 Oct 2025 15:42:01 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id C5F77117A932D; Tue, 28 Oct 2025 16:41:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1761666120; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=nDSVs9lhw+F4YKSYneSSWC5JzdOFTeNiVqf0bisny44=; b=YZlIzKDI2uuOlCIyIc2f7SjHrk4BtxyZB5m8F2TanV1WkB0xo4/Bl/0fnuCZqdFFWFLxVJ Y6tFo4ygPXXz0LK5Db9RC/r7PvBfOfS2RSB0fJAum4Sh2GIsVUnXLuOy+4TAyEVxUVt0ng r8u6miAXNCJKzQLpgWPhQm1TuF9itzKJVfNvcV4H2xhpHGbwbo8zCrSnI4fLpFfQMwDS2M f3ub86hwLg7UELL40PKCVuccrdieUDLaE8U6TT/RtNeXBr8DHKDBB8xgk3YbbA7tcLR0Da orq83w3vBtzziMwPNeXpYalN6/SxLjEyz5HMqz36hTPft03JfG6n5bdgBMYPMg== From: Miquel Raynal To: Santhosh Kumar K Cc: , , , , , , , , , , , , Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller In-Reply-To: (Santhosh Kumar K.'s message of "Sat, 20 Sep 2025 23:25:31 +0530") References: <20250811193219.731851-1-s-k6@ti.com> <20250811193219.731851-2-s-k6@ti.com> <87seguemzu.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Tue, 28 Oct 2025 16:41:51 +0100 Message-ID: <87qzunt4n4.fsf@bootlin.com> MIME-Version: 1.0 X-Last-TLS-Session-Version: TLSv1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251028_084205_843614_19704A1A X-CRM114-Status: GOOD ( 46.16 ) 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 SGVsbG8gU2FudGhvc2gsCgpPbiAyMC8wOS8yMDI1IGF0IDIzOjI1OjMxICswNTMwLCBTYW50aG9z aCBLdW1hciBLIDxzLWs2QHRpLmNvbT4gd3JvdGU6Cgo+IEhlbGxvLAo+Cj4gT24gMTAvMDkvMjUg MTM6NTEsIE1pcXVlbCBSYXluYWwgd3JvdGU6Cj4+IE9uIDEyLzA4LzIwMjUgYXQgMDE6MDI6MTAg KzA1MzAsIFNhbnRob3NoIEt1bWFyIEsgPHMtazZAdGkuY29tPiB3cm90ZToKPj4gCj4+PiBGcm9t OiBQcmF0eXVzaCBZYWRhdiA8cHJhdHl1c2hAa2VybmVsLm9yZz4KPj4+Cj4+PiBTb21lIGNvbnRy b2xsZXJzIGxpa2UgdGhlIENhZGVuY2UgT1NQSSBjb250cm9sbGVyIG5lZWQgdG8gcGVyZm9ybSBh Cj4+PiB0dW5pbmcgc2VxdWVuY2UgdG8gb3BlcmF0ZSBhdCBoaWdoIGRhdGEgcmF0ZXMuIFR1bmlu ZyBpcyBuZWVkcyB0byBoYXBwZW4KPj4+IG9uY2UgdGhlIGRldmljZSBpcyBzd2l0Y2hlZCB0byBh cHByb3ByaWF0ZSBtb2RlIChzYXkgOFMtOFMtOFMgb3IKPj4+IDhELThELThEKS4KPgo+IEFwb2xv Z2llcyBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbnNlIC0gSSBzdGFydGVkIHByb3RvdHlwaW5nIG5l dyBzb2x1dGlvbgo+IGJhc2VkIG9uIG91ciBkaXNjdXNzaW9ucyBlYXJsaWVyLCB3aGljaCB0b29r IHNvbWUgYWRkaXRpb25hbCB0aW1lLgoKTXkgdHVybiB0byBhcG9sb2dpemUgZm9yIHRoZSBkZWxh eSwgZXNwZWNpYWxseSBzaW5jZSB5b3VyIGZlZWRiYWNrIGlzCnZlcnkgY29tcGxldGUuCgo+PiBU aGlzIGlzIGFjdHVhbGx5IHdyb25nLiBUdW5pbmcgaXMgd2F5IG1vcmUgZ2VuZXJpYyB0aGFuIHRo YXQgOikKPj4gSWYgc29tZW9uZSB3YW50cyB0byB1c2UgYSBjaGlwIGF0IGEgaGlnaCBmcmVxdWVu Y3kgKDUwTUh6IGluIHlvdXIKPj4gY2FzZSwKPj4gYnV0IHdoYXRldmVyLCB0aGVyZSBpcyBhIHRo cmVzaG9sZCBhYm92ZSB3aGljaCBhZGRpdGlvbmFsIGNhcmUgbXVzdCBiZQo+PiB0YWtlbiksIGl0 IG11c3QgZ28gdGhyb3VnaCB0aGUgY2FsaWJyYXRpb24gc3RlcC4gSXQgZG9lcyBub3QgbWF0dGVy IGluCj4+IHdoaWNoIG1vZGUgeW91IGFyZS4gQ2FsaWJyYXRpb24gd291bGQgc3RpbGwgYmUgcmVs ZXZhbnQgaW4gc2luZ2xlIFNEUgo+PiBtb2RlLgo+PiBUaGlzIDUwTUh6IGJvdGhlcmVkIE1hcmsg YmVjYXVzZSBpdCBpcyB0b28gQ2FkZW5jZSBzcGVjaWZpYy4gTWF5YmUKPj4gdGhpcwo+PiBzaG91 bGQgYmUgYSBjb250cm9sbGVyIHBhcmFtZXRlcj8gSWYgdGhlIHNwaS1tZW0gY29yZSAob3IgZXZl biB0aGUgc3BpCj4+IGNvcmUsIGJ5IGV4dGVuc2lubykgc2VlcyB0aGF0IHRoZSBkZXNpZ24gYWxs b3dzIHJ1bm5pbmcgYXQgWE1IeiAoZHVlIHRvCj4+IHRoZSBTUEkgcGVyaXBoZXJhbCBwcm9wZXJ0 aWVzIG9yIHNpbXBseSB0aGUgYWJzZW5jZSBvZiBhbnkgbGltaXRhdGlvbiksCj4+IGFuZCBpZiB0 aGUgY29udHJvbGxlciBzdGF0ZXMgdGhhdCBpdCByZXF1aXJlcyBhbiBleHRyYSB0dW5pbmcgc3Rl cCBhYm92ZQo+PiBZTUh6IChhbmQgWCA+IFkpLCB0aGVuIGl0IGxhdW5jaGVzIHRoZSBjYWxpYnJh dGlvbi4KPj4gIEZyb20gYSBjb3JlIHBlcnNwZWN0aXZlLCBJIHdvdWxkIGxpa2UgdGhlIGNhbGli cmF0aW9uIGhvb2sgdG8gYmUgYXMKPj4gc2ltcGxlIGFzIHBvc3NpYmxlLCBiZWNhdXNlIHdoYXQg ImNhbGlicmF0aW9uIiBtZWFucyBpcyBoaWdobHkKPj4gY29udHJvbGxlciBhbmQgY2hpcCBzcGVj aWZpYy4KPgo+IEkgdW5kZXJzdGFuZCB0aGUgY29uY2VybiBoZXJlLgo+Cj4gTGV0IG1lIHBvaW50 IG91dCB0aGUgb3B0aW9ucyBmb3IgbGF1bmNoaW5nIHRoZSB0dW5pbmcgcHJvY2VkdXJlLCBhbG9u Zwo+IHdpdGggdGhlIGlzc3VlcyBpbiBlYWNoIGFwcHJvYWNoLgoKVmVyeSBnb29kIHN1bW1hcnku Cgo+IE9wdGlvbiAxOiBMYXVuY2ggdHVuaW5nIGFzIHBhcnQgb2Ygc3BpX21lbV9leGVjX29wKCkK PiAgICAtIEFmdGVyIHNwaV9tZW1fYWNjZXNzX3N0YXJ0KCksIGludHJvZHVjZSBhIHNwaV9tZW1f bmVlZHNfdHVuaW5nKCkKPiBjaGVjayAoYSBuZXcgY2FsbGJhY2sgdG8gU1BJIE1FTSBjb250cm9s bGVyKSB0byBjaGVjayB3aGV0aGVyIHRoZQo+IGN1cnJlbnQgb3AgcmVxdWlyZXMgdHVuaW5nCj4g ICAgLSBJZiB5ZXMsIHdlIGNhbGwgc3BpX21lbV9leGVjdXRlX3R1bmluZygpCj4gICAgICAgICAt IG9uIHN1Y2Nlc3MsIG1hcmsgdHVuaW5nIGNvbXBsZXRlIGluIGEgZmxhZyB3aXRoaW4gU1BJIE1F TQo+IENvbnRyb2xsZXIgcHJpdmF0ZSBkYXRhCj4gICAgICAgICAtIG9uIGZhaWx1cmUsIHdlIGF0 dGVtcHQgYSBmYWxsYmFjayBieSBjYWxsaW5nCj4gc3BpX21lbV9hZGp1c3Rfb3BfZnJlcSgpIGFu ZCBkcm9wIHRvIGEgbG93ZXIgc3VwcG9ydGVkIGZyZXF1ZW5jeQo+Cj4gT3B0aW9uIDI6IExhdW5j aCB0dW5pbmcgd2l0aGluIHNwaV9jb250cm9sbGVyLT5leGVjX29wKCkgaW1wbGVtZW50YXRpb24K PiAgICAtIFZlcnkgc2ltaWxhciB0byBvcHRpb24gMSwgZXhjZXB0IHRoYXQgdGhlIHNwaV9tZW1f ZXhlY3V0ZV90dW5pbmcoKQo+IGlzIHRyaWdnZXJlZCBmcm9tIHdpdGhpbiB0aGUgY29udHJvbGxl cidzIGV4ZWNfb3AoKSBpbXBsZW1lbnRhdGlvbgo+IChubyBuZWVkIGZvciBzcGlfbWVtX25lZWRz X3R1bmluZygpKQo+Cj4gRHJhd2JhY2tzIGluIG9wdGlvbiAxIGFuZCAyOgo+ICAgIC0gVHVuaW5n IHJlcXVpcmVzIG11bHRpcGxlIHJlYWRzIG9mIGEga25vd24gcGF0dGVybiwgYnV0IHRoZSBmbGFz aAo+IG1heSBub3QgYWx3YXlzIGJlIGluIGEgc3RhdGUgdG8gYWxsb3cgcmVhZCBjb21tYW5kcwo+ ICAgIC0gTm8gZmFsbGJhY2sgb24gZmFpbHVyZXMsIGNhbid0IG1ha2UgZmxhc2gtc3BlY2lmaWMg YWRqdXN0bWVudHMgaW4KPiBjYXNlIG9mIGEgdHVuaW5nIGZhaWx1cmUKPiAgICAtIE5vIGFjY2Vz cyB0byB3cml0ZV9vcCgpIHRvIHdyaXRlIGtub3duIHBhdHRlcm4gdGVtcG9yYXJpbHkgdG8gYW4K PiBvbi1kaWUgY2FjaGUuIFBhdHRlcm4gbmVlZHMgdG8gYmUgYWx3YXlzIGJ1cm50IGludG8gdGhl IGZsYXNoCj4KPiAgICAtIFBsdXMsIGluIG9wdGlvbiAyIC0gd2UgY2FuJ3QgY2FsbCBzcGlfbWVt X2FkanVzdF9vcF9mcmVxKCkKClR3byBtb3JlIHNpZ25pZmljYW50IGRyYXdiYWNrczoKLSBpdCBh ZGRzIGFuIGV4dHJhIHN0ZXAgaW4gdGhlICJmYXN0IHBhdGgiIC1tYXliZSBuZWdsaWdpYmxlPy0K LSBzcGlfbWVtX2V4ZWNfb3AoKS8tPmV4ZWNfb3AoKSBhcmUgY2FsbGVkIHdheSBiZWZvcmUgYmVp bmcgcmVhZHkgZm9yCiAgY2FsaWJyYXRpb24uCgo+IFdoaWxlIHRoZSBuZWVkIGZvciB0dW5pbmcg aXMgZGljdGF0ZWQgYnkgQ29udHJvbGxlciBzcGVjaWZpYwo+IGNoYXJhY3RlcmlzdGljcyB0aGUg b3BzIChhbmQgc3RhdGUgb2YgdGhlIGNoaXApIHJlcXVpcmVkIHRvIGNvbXBsZXRlCj4gdHVuaW5n IGlzIHVuZGVyIHRoZSBjb250cm9sIG9mIHNwaS1tZW0gdXNlcnMgKHNwaS1uYW5kL3NwaS1ub3Ip Lgo+IFNvLCBpdCdzIGltcG9zc2libGUgdG8gYWNoaWV2ZSB0dW5pbmcgd2l0aG91dCB0aGUgaGVs cCBvZiBzcGktbWVtIHVzZXJzLgoKU291bmRzIGxpa2UgYSBjb25zdHJhaW50IHdlIGNhbiBhZmZv cmQgaW5kZWVkLCBlc3BlY2lhbGx5IHNpbmNlIHRoZSBvcHMKdGhhdCBjYW4gYmUgb3B0aW1pemVk LCBhcmUgZmxhc2ggc3BlY2lmaWMgKHJlbGF0aXZlbHkgZmV3IGNvbnRlbnQgdG8Kc2hhcmUgYmV0 d2VlbiBzcGkgbm9yIGFuZCBzcGkgbmFuZCkuCgo+IFNvLCBPcHRpb24gMzogTGF1bmNoIGZyb20g U1BJIE1FTSBjbGllbnRzCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAobXRkL25hbmQvc3Bp IG9yIG10ZC9zcGktbm9yLCBldGMuLCkKPiAgICAtIE9uY2UgdGhlIHNwaS1tZW0gY2hpcCBpcyBj b21wbGV0ZWx5IGVudW1lcmF0ZWQgYW5kIGJlc3QgcmVhZCBhbmQKPiB3cml0ZSBvcHMgYXJlIGNo b3NlbiBjYWxsIHNwaV9tZW1fbmVlZHNfdHVuaW5nKHJlYWRfb3AsIHdyaXRlX29wKSBhcwo+IGEg cGFydCBvZiAucHJvYmUoKQoKVGhpcyBsb29rcyBsaWtlIGEgZGVjZW50IHBsYWNlLCBidXQgdGhl cmUgaXMgb25lIGxpbWl0YXRpb24gdG8Kd29ya2Fyb3VuZDogcGlja2luZyBiZXN0IHJlYWQgYW5k IHdyaXRlIG9wcyByZXF1aXJlIGtub3dpbmcgd2hhdCB0aGUKY29udHJvbGxlciBpcyBjYXBhYmxl IG9mIGluIHRlcm1zIG9mIGZyZXF1ZW5jeSwgd2hpY2ggbWVhbnMgd2UgbXVzdCBpbgphZHZhbmNl IGV4cGVjdCB0byBzZXQgdXAgY2FsaWJyYXRpb24gb3Igbm90LiBJIGRvbid0IHRoaW5rIGl0J3Mg YQpwcm9ibGVtLCB0aGlzIGlzIHNvbWV0aGluZyB3ZSBrbm93IGluIGFkdmFuY2UgdGhhbmtzIHRv CmVnLiBzcGktbWF4LWZyZXF1ZW5jeSBpbiB0aGUgRFQsIGJ1dCBJIHN0aWxsIHRoaW5rIGEgY29u dHJvbGxlciBzcGVjaWZpYwoibWF4aW11bSBmcmVxdWVuY3kgd2l0aG91dCBjYWxpYnJhdGlvbiIg Y2FwYWJpbGl0eSBtdXN0IGJlIGNhcnJpZWQgZm9yCnRoZSBjb250cm9sbGVyIHRvIGRlY2lkZSB3 aGV0aGVyIHRoaXMgc3RlcCBpcyBuZWVkZWQgb3Igbm90IHdoZW4gYXNrZWQKYnkgdGhlIHNwaSBt ZW0gY2xpZW50LgoKPiAgICAtIElmIHR1bmluZyBpcyByZXF1aXJlZCwgY2FsbAoKSSBndWVzcyAi dHVuaW5nIGJlaW5nIHJlcXVpcmVkIiBpcyBhIGNvbnRyb2xsZXIgY2hvaWNlLCBiYXNlZCBvbiB0 aGUKdGFyZ2V0IGZyZXF1ZW5jeSBmb3IgYm90aCByZWFkL3dyaXRlIG9wcyBhbmQgdGhlIGNvbnRy b2xsZXIgY2FwYWJpbGl0eQp0byBhY2hpZXZlIHRoaXMuCgo+IHNwaV9tZW1fZXhlY3V0ZV90dW5p bmcocmVhZF9vcCwgd3JpdGVfb3ApCj4gICAgICAgICAtIElmIG9ubHkgcmVhZF9vcCBpcyBwcm92 aWRlZCwgaXQgaW1wbGllcyB0aGUgdHVuaW5nIHBhdHRlcm4gaXMKPiBwcmUtZmxhc2hlZCB0byB0 aGUgcGFydGl0aW9uCgpJbnRlcmVzdGluZy4gSSBndWVzcyB0aGF0IGxpdmVzIHNvbWUgcm9vbSBm b3IgdHVuaW5nIFBIWXMgZHVyaW5nIHdyaXRlcyBhcwp3ZWxsIHdpdGhvdXQgbW9yZSBjb3JlIG1v ZGlmaWNhdGlvbnMgbGF0ZXIsIGlzbid0IGl0PwoKPiAgICAtIE9uIHR1bmluZyBmYWlsdXJlLCBy ZXRyeSBieSByZS1ydW5uaW5nIHNwaV9tZW1fbmVlZHNfdHVuaW5nKCkgd2l0aAo+IHRoZSBzZWNv bmQgYmVzdCBzZXQgb2Ygb3BzIChtYXggdGhyb3VnaHB1dCAtIDEpCgpJIHdvdWxkIGxpa2UgdG8g Y2hhbGxlbmdlIHRoaXMgbmVlZC4gQ2FuIHRoZSBzYW1lIGNhbGlicmF0aW9uIGZhaWwgaWYKYXR0 ZW1wdGVkIG11bHRpcGxlIHRpbWVzIChlZy4gYmVjYXVzZSBvZiB0aGUgaGVhdD8pIElmIHllcywg dGhlbiB3ZSBuZWVkCmEgZmFsbGJhY2sgaW5kZWVkLiBPdGhlcndpc2UsIEknZCBiZSBpbiBmYXZv ciBvZiBqdXN0IGZhaWxpbmcgdGhlCnByb2JlLiBDYWxpYnJhdGlvbiBpcyBhbiBvcHQtaW4gLT4g dXNlcnMgbXVzdCBhbGxvdyBhIGhpZ2hlciBmcmVxdWVuY3kKdGhhbiB0aGV5IHVzZSB0byBpbiBv cmRlciB0byBlbmFibGUgdGhlIGZlYXR1cmU/Cgo+IFdpdGggb3B0aW9uIDMsIHNwaV9tZW0gdXNl cnMgYXJlIGxpbWl0ZWQgdG8gY2FsbGluZwo+IHNwaV9tZW1fbmVlZHNfdHVuaW5nKCkgYW5kIHNw aV9tZW1fZXhlY3V0ZV90dW5pbmcoKS4KCkkgd291bGQgZXZlbiBnbyBmb3IgYSBzaW5nbGUgc3Bp X21lbV90dW5lX3BoeSgpPyBPciBpcyB0aGVyZSBhIHBvaW50IGluCmhhdmluZyB0d28gaGVscGVy cz8KCj4gUmVzdCBpcyBoaWRkZW4KPiB3aXRoaW4gdGhlIGNvbnRyb2xsZXIgZHJpdmVycy4gSWYg c3BpLW1lbSB1c2VycyBjaGFuZ2UgcmVhZC93cml0ZSBvcHMsCj4gdGhlIGFib3ZlIHNlcXVlbmNl IGNhbiBiZSByZS1pc3N1ZWQuCgpJIGRvbid0IGhhdmUgdXNlIGNhc2VzIGZvciB0aGF0IGluIG1p bmQsIGJ1dCB3aHkgbm90LgoKPiBUaGUgY29udHJvbGxlciBjYW4gc3RvcmUgdGhlIHJlYWRfb3Ag YW5kIHdyaXRlX29wIGluIGNhc2Ugb2YgYSB0dW5pbmcKPiBzdWNjZXNzIGFuZCBwZXJpb2RpY2Fs bHkgcmUtcnVuIHR1bmluZywgZW5zdXJpbmcgd2UgYWx3YXlzIGhhdmUgdmFsaWQKPiB0dW5pbmcg cGFyYW1ldGVycy4KCllvdSdsbCBoYXZlIHRvIG1ha2Ugc3VyZSB5b3Ugb25seSB1c2UgUEhZIGNh bGlicmF0aW9uIGZvciB0aGUgb3BzIHRoYXQKaGF2ZSBiZWVuIHVzZWQgZm9yIHRoZSB0dW5pbmcg dGhvdWdoLCBiZWNhdXNlIGZvciBleGFtcGxlIGFzIEkgYW0Kd29ya2luZyBvbiBvY3RhbCBERFIg c3VwcG9ydDogZHVyaW5nIFMyUkFNIHRoZXJlIG1heSBiZSB0aGUgbmVlZCBmb3IKcmV0dXJuaW5n IHRvIFNEUiBtb2RlLCB3aGljaCBpbiB0dXJucyB3aWxsIGhhdmUgdG8gd29yayB3aXRob3V0IHRo ZQp0dW5pbmcgKHR1bmluZyBwYXJhbWV0ZXJzIHdpbGwgYmUgaW5jb3JyZWN0IGZvciB0aGlzIG1v ZGUgZm9yIHRoZSB0aW1lCndlIHJ1biBzbG93bHkpLiBTbyBlaXRoZXIgdGhlIGNvbnRyb2xsZXIg a25vd3Mgd2hpY2ggb3BlcmF0aW9uIHNob3VsZAplbmFibGUgUEhZIG9wdGltaXphdGlvbnMsIG9y IHdlIG11c3QgcGVyZm9ybSB0aGUgd2hvbGUgY2FsaWJyYXRpb24gYWdhaW4KZXZlcnkgdGltZSB3 ZSBzdXNwZW5kIChtZWgpLgoKPiBPbmUgY29uY2VybiB3aXRoIG9wdGlvbiAzIGlzIHRoYXQgd2Ug bWF5IG5vdCBiZSBhYmxlIHRvIG1ha2UgdXNlIG9mCj4gc3RhdGljIGRhdGEgb24gY2VydGFpbiBm bGFzaCBhcyB0dW5pbmcgcGF0dGVybnMgKGxpa2UgcmVhZGluZyBwYXJhbWV0ZXIKPiBwYWdlIG9y IFNGRFAgdGFibGUgZm9yIHR1bmluZyBpbnN0ZWFkIG9mIGNvbnRyb2xsZXIgc3BlY2lmaWMgYXR0 YWNrCj4gcGF0dGVybnMpLgoKVGhpcyBpcyB0cnVlLCBJIGtub3cgc29tZSBkZXZpY2VzIGNhbiBz ZW5kIHBhdHRlcm5zIGR1cmluZyBkdW1teSBjeWNsZXMKYnkgSSBoYXZlIG5vIGlkZWEgaG93IHBv d2VyZnVsIHRoYXQgaXMsIG5vciBpZiBpdCBjYW4gYWN0dWFsbHkgYmUgdXNlZAppbiBMaW51eC4g T25lIG5lZWQgYSBjb250cm9sbGVyIHRoYXQgaXMgYXdhcmUgb2YgdGhlc2UgYml0cyBhbmQgY2Fu Cml0c2VsZiBhZGp1c3QvZmluZSB0dW5lIGl0cyBvd24gY29uZmlndXJhdGlvbi4gRm9yIG5vdywg SSBwcm9wb3NlIHRvIGxldAp0aGlzIGFzaWRlIHVudGlsIHdlIGdldCByZWFsIGhhcmR3YXJlIHRo YXQgY2FuIGJlIHRlc3RlZC4KCj4gUGxlYXNlIGxldCBtZSBrbm93IHlvdXIgdGhvdWdodHMgb24g d2hpY2ggb2YgdGhlc2UgZGlyZWN0aW9ucyBtYWtlcyB0aGUKPiBtb3N0IHNlbnNlLgoKTGV0J3Mg Z290IGZvciBvcHRpb24gMy4gSSdtIGVhZ2VyIHRvIHNlZSB0aGlzIG1vdmluZyBmb3J3YXJkIQoK VGhhbmtzLCBNaXF1w6hsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KTGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9s aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRkLwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 459241FF7D7 for ; Tue, 28 Oct 2025 15:42:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761666134; cv=none; b=Baf0IGgW7FDcGYHN386G5zJyunenyw9PFFtLJdaS+TdUXG/CXHHaKEIKyGa6HBviA9y+CKsuLBiGeJ5hrlGj0IRSsN4N8KRiQDNILl0Sx0Bnf//g5PWRqsouxZtc0EbrRrKfVTHpdwU4G9OXfDzGw2kAchxfIOFnZ6ptm2GC0vo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761666134; c=relaxed/simple; bh=nmb9otoxS9qo4PpMlQE1HojBqVA53t1oBHFeByRsR9Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=qVGWvY/YkKxy2PAJ+yKwlUKbaVKrZ+0ehEHHKA3zlFTSd158QOMGk+xQZ1mhKEGXPsQsAgxKTGa06RB5Krc4LKrzVoIRDVWG0IL7hQnW/WHgLcRwgx6REx0nT+tinz4MJ3zKpQcG2af8qLavrf5WWhMoz16gisvOGQ8umSMbhh8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=YZlIzKDI; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="YZlIzKDI" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 7B7D94E41397; Tue, 28 Oct 2025 15:42:01 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 44E7B606AB; Tue, 28 Oct 2025 15:42:01 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id C5F77117A932D; Tue, 28 Oct 2025 16:41:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1761666120; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=nDSVs9lhw+F4YKSYneSSWC5JzdOFTeNiVqf0bisny44=; b=YZlIzKDI2uuOlCIyIc2f7SjHrk4BtxyZB5m8F2TanV1WkB0xo4/Bl/0fnuCZqdFFWFLxVJ Y6tFo4ygPXXz0LK5Db9RC/r7PvBfOfS2RSB0fJAum4Sh2GIsVUnXLuOy+4TAyEVxUVt0ng r8u6miAXNCJKzQLpgWPhQm1TuF9itzKJVfNvcV4H2xhpHGbwbo8zCrSnI4fLpFfQMwDS2M f3ub86hwLg7UELL40PKCVuccrdieUDLaE8U6TT/RtNeXBr8DHKDBB8xgk3YbbA7tcLR0Da orq83w3vBtzziMwPNeXpYalN6/SxLjEyz5HMqz36hTPft03JfG6n5bdgBMYPMg== From: Miquel Raynal To: Santhosh Kumar K Cc: , , , , , , , , , , , , Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller In-Reply-To: (Santhosh Kumar K.'s message of "Sat, 20 Sep 2025 23:25:31 +0530") References: <20250811193219.731851-1-s-k6@ti.com> <20250811193219.731851-2-s-k6@ti.com> <87seguemzu.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Tue, 28 Oct 2025 16:41:51 +0100 Message-ID: <87qzunt4n4.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-spi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Hello Santhosh, On 20/09/2025 at 23:25:31 +0530, Santhosh Kumar K wrote: > Hello, > > On 10/09/25 13:51, Miquel Raynal wrote: >> On 12/08/2025 at 01:02:10 +0530, Santhosh Kumar K wrote: >>=20 >>> From: Pratyush Yadav >>> >>> Some controllers like the Cadence OSPI controller need to perform a >>> tuning sequence to operate at high data rates. Tuning is needs to happen >>> once the device is switched to appropriate mode (say 8S-8S-8S or >>> 8D-8D-8D). > > Apologies for the delay in response - I started prototyping new solution > based on our discussions earlier, which took some additional time. My turn to apologize for the delay, especially since your feedback is very complete. >> This is actually wrong. Tuning is way more generic than that :) >> If someone wants to use a chip at a high frequency (50MHz in your >> case, >> but whatever, there is a threshold above which additional care must be >> taken), it must go through the calibration step. It does not matter in >> which mode you are. Calibration would still be relevant in single SDR >> mode. >> This 50MHz bothered Mark because it is too Cadence specific. Maybe >> this >> should be a controller parameter? If the spi-mem core (or even the spi >> core, by extensino) sees that the design allows running at XMHz (due to >> the SPI peripheral properties or simply the absence of any limitation), >> and if the controller states that it requires an extra tuning step above >> YMHz (and X > Y), then it launches the calibration. >> From a core perspective, I would like the calibration hook to be as >> simple as possible, because what "calibration" means is highly >> controller and chip specific. > > I understand the concern here. > > Let me point out the options for launching the tuning procedure, along > with the issues in each approach. Very good summary. > Option 1: Launch tuning as part of spi_mem_exec_op() > - After spi_mem_access_start(), introduce a spi_mem_needs_tuning() > check (a new callback to SPI MEM controller) to check whether the > current op requires tuning > - If yes, we call spi_mem_execute_tuning() > - on success, mark tuning complete in a flag within SPI MEM > Controller private data > - on failure, we attempt a fallback by calling > spi_mem_adjust_op_freq() and drop to a lower supported frequency > > Option 2: Launch tuning within spi_controller->exec_op() implementation > - Very similar to option 1, except that the spi_mem_execute_tuning() > is triggered from within the controller's exec_op() implementation > (no need for spi_mem_needs_tuning()) > > Drawbacks in option 1 and 2: > - Tuning requires multiple reads of a known pattern, but the flash > may not always be in a state to allow read commands > - No fallback on failures, can't make flash-specific adjustments in > case of a tuning failure > - No access to write_op() to write known pattern temporarily to an > on-die cache. Pattern needs to be always burnt into the flash > > - Plus, in option 2 - we can't call spi_mem_adjust_op_freq() Two more significant drawbacks: - it adds an extra step in the "fast path" -maybe negligible?- - spi_mem_exec_op()/->exec_op() are called way before being ready for calibration. > While the need for tuning is dictated by Controller specific > characteristics the ops (and state of the chip) required to complete > tuning is under the control of spi-mem users (spi-nand/spi-nor). > So, it's impossible to achieve tuning without the help of spi-mem users. Sounds like a constraint we can afford indeed, especially since the ops that can be optimized, are flash specific (relatively few content to share between spi nor and spi nand). > So, Option 3: Launch from SPI MEM clients > (mtd/nand/spi or mtd/spi-nor, etc.,) > - Once the spi-mem chip is completely enumerated and best read and > write ops are chosen call spi_mem_needs_tuning(read_op, write_op) as > a part of .probe() This looks like a decent place, but there is one limitation to workaround: picking best read and write ops require knowing what the controller is capable of in terms of frequency, which means we must in advance expect to set up calibration or not. I don't think it's a problem, this is something we know in advance thanks to eg. spi-max-frequency in the DT, but I still think a controller specific "maximum frequency without calibration" capability must be carried for the controller to decide whether this step is needed or not when asked by the spi mem client. > - If tuning is required, call I guess "tuning being required" is a controller choice, based on the target frequency for both read/write ops and the controller capability to achieve this. > spi_mem_execute_tuning(read_op, write_op) > - If only read_op is provided, it implies the tuning pattern is > pre-flashed to the partition Interesting. I guess that lives some room for tuning PHYs during writes as well without more core modifications later, isn't it? > - On tuning failure, retry by re-running spi_mem_needs_tuning() with > the second best set of ops (max throughput - 1) I would like to challenge this need. Can the same calibration fail if attempted multiple times (eg. because of the heat?) If yes, then we need a fallback indeed. Otherwise, I'd be in favor of just failing the probe. Calibration is an opt-in -> users must allow a higher frequency than they use to in order to enable the feature? > With option 3, spi_mem users are limited to calling > spi_mem_needs_tuning() and spi_mem_execute_tuning(). I would even go for a single spi_mem_tune_phy()? Or is there a point in having two helpers? > Rest is hidden > within the controller drivers. If spi-mem users change read/write ops, > the above sequence can be re-issued. I don't have use cases for that in mind, but why not. > The controller can store the read_op and write_op in case of a tuning > success and periodically re-run tuning, ensuring we always have valid > tuning parameters. You'll have to make sure you only use PHY calibration for the ops that have been used for the tuning though, because for example as I am working on octal DDR support: during S2RAM there may be the need for returning to SDR mode, which in turns will have to work without the tuning (tuning parameters will be incorrect for this mode for the time we run slowly). So either the controller knows which operation should enable PHY optimizations, or we must perform the whole calibration again every time we suspend (meh). > One concern with option 3 is that we may not be able to make use of > static data on certain flash as tuning patterns (like reading parameter > page or SFDP table for tuning instead of controller specific attack > patterns). This is true, I know some devices can send patterns during dummy cycles by I have no idea how powerful that is, nor if it can actually be used in Linux. One need a controller that is aware of these bits and can itself adjust/fine tune its own configuration. For now, I propose to let this aside until we get real hardware that can be tested. > Please let me know your thoughts on which of these directions makes the > most sense. Let's got for option 3. I'm eager to see this moving forward! Thanks, Miqu=C3=A8l