From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gw2.atmark-techno.com (gw2.atmark-techno.com [35.74.137.57]) (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 EDEE16FC3 for ; Wed, 26 Aug 2026 09:03:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=35.74.137.57 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787735020; cv=none; b=TpZxWHJ4MwVJBWjVhh0PYJB2nZD3bVGiYlw2SypGMDGpOX8MheqKBjef24UjiLOzVmFl770Ya/9g+Zt6U+fJC4YyVvIJ6sdLAll1a9LFmM4UOpN6QhvRuZeEcssGmS15uYBO3uVex06ADNTu66QO+BawK8TRLLt4yfAUSSLsLnc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787735020; c=relaxed/simple; bh=3WVb2ewVHbQa4aGbflsDB14+bU5UZTUkb+ERXWMkcNY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jsocoZ7ileOd41vBeYlzycfiwS8fTrUIH92ommneOrnAbdIsCmAWNeqAj4NlorJ3+ntBnQlNeiNPMBY1QyPncQLMyBfhlO6GkM+nOtWap7pk3lqiIRtE9D6K0LAA8UX6ncJipo7rSM2bcfXsjH7YgP02u/mKaXc3OnutNa02T/w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=atmark-techno.com; spf=pass smtp.mailfrom=atmark-techno.com; dkim=pass (2048-bit key) header.d=atmark-techno.com header.i=@atmark-techno.com header.b=ZDiFKVE/; arc=none smtp.client-ip=35.74.137.57 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=atmark-techno.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=atmark-techno.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=atmark-techno.com header.i=@atmark-techno.com header.b="ZDiFKVE/" Authentication-Results: gw2.atmark-techno.com; dkim=pass (2048-bit key; unprotected) header.d=atmark-techno.com header.i=@atmark-techno.com header.a=rsa-sha256 header.s=google header.b=ZDiFKVE/; dkim-atps=neutral Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by gw2.atmark-techno.com (Postfix) with ESMTPS id 825DC1FF for ; Wed, 26 Aug 2026 18:03:32 +0900 (JST) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2d04908139bso11920335ad.2 for ; Wed, 26 Aug 2026 02:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atmark-techno.com; s=google; t=1787735011; x=1788339811; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=gd/7CGcQOnI8K4fUjyfMWBBAL5IDTfpF3taYM7+n2AM=; b=ZDiFKVE/EKDMyRZHTQ0hMidXYu+f3dRuk2Ab7Dxs3v0AEZHaHejg2pDV1MGQfQhg7L R73m+1IVnPu8tJPJRPIwWL/3hWjITgYsM3x2tPhLWse8fxZvMBvImJZLYEOnTly7EKb3 zeip9rd1TklL5Yigm8kwBNjNaGVMOyizKtOVWaXmULSNA4fYYCHLX4RCQ8rVqrSqxu4M I0Dc3XFzauyPqXgF732nc7AdWnCcLI9HBl615J83XRrq1pd7NXXgclIdGI9+yzAos4FG 2E+FouXju3jayor1xvhzzaZK7spP4/MrDhLYietJiGRJT6CWHMrMJwe/7tie80rJ/ncf uQsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787735011; x=1788339811; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=gd/7CGcQOnI8K4fUjyfMWBBAL5IDTfpF3taYM7+n2AM=; b=mhv+7gIusp3A/dVpiM1swQf1RMwbL1Stkoum4hwBxq6IJ3wp0fv5tI49raK+We6ir1 MwMRv+w4N8J55AZvElXK/rwz5E/A4u/iBj+/wqjaK83jImCZ1lcX+IGrCu6M3S0QS+kz 9Te2oqb0JJjA/U74HLdZVDV7KPHOkNU+A81LgeBnj5K3ylapQYMOtN4VYJI+qIDNmIB0 VAlHA8XRtcK+dwtZtdlAnFrcnB7TjcK61gttS52Tg2D3vLH5cbh0ARooHJLwxYnqcyOm pBaMmAo3ElIpEkKu9wSancCcksQAY1B0nEQ62fhrpBkW7TfDBTL4lCLsVvhJswq7VRKG C8XQ== X-Forwarded-Encrypted: i=1; AHgh+RrVPte6dVjzihwhKDZa/khxcINXXLnZLrONNZhl12VHMOYKCcEpPhnsUjccS7AkohcpfEKN9Vy1S4hmxds=@vger.kernel.org X-Gm-Message-State: AFuF++m9xJMKKThMt5D/cXcp6sQP7BEOr2mDWbvceN29bbOmyq7Ov9tp 3PoMSgFERnrK8v/EpAuEp3XbFmuNhDMGFFFHUwCy2go8Xjk9YwarObijUfzCzMQXGwl1JvPzpFu koOqs8yfI9p55AuPbcJcoORNjVAKA0uUYn2RM5mQCMWq9owhrruQzZuEhRNcqAhGtEgdk22+x/l E= X-Gm-Gg: AR+sD13VyyN3d5TIFZdzqIEvXTBzCVK6VHJAzIRHsHhS8snP+ymrZE3pIIZf2jTbqhm Mf1GmP0p8z9jr81wNEHGgh29ANdYmFjBT7QRp4gtDD+QuuxVAOVl+tNr9vlRVkMYZRmzX7t4AGE KGyRGl7dMedP/vwgSSLbLq9mGzEyRZf4ULK5Kx8Fn6B2bgbVod+ccKhfQemCSdDvrn6q/G548Td ECE1RHrm/TIYD3Mst3hG1NUh9mbGO5/VAhxWHjpm7HkhlOHr/SGSgmd2/gunlP9GXIBIZfbOexd E/DvggcnR39vbiRc6kyvhPaH8HQL7CN/RDkScEUC09YBnsQ/ZseNOD7vBmzfoDr+rDVJ3B2f5ww wRlZ1k1Qupmmw7cE7nz7M/2M93YgS63PmtqCHRF5xtUpdRjjS X-Received: by 2002:a17:90b:1d47:b0:38f:aab1:5148 with SMTP id 98e67ed59e1d1-3966d8ab6e3mr11165618a91.13.1787735011440; Wed, 26 Aug 2026 02:03:31 -0700 (PDT) X-Received: by 2002:a17:90b:1d47:b0:38f:aab1:5148 with SMTP id 98e67ed59e1d1-3966d8ab6e3mr11165541a91.13.1787735010999; Wed, 26 Aug 2026 02:03:30 -0700 (PDT) Received: from localhost (sodcd-04p2-40.ppp11.odn.ad.jp. [203.139.65.40]) by smtp.gmail.com with UTF8SMTPSA id 98e67ed59e1d1-396686e8aa2sm3218947a91.3.2026.08.26.02.03.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Aug 2026 02:03:30 -0700 (PDT) Date: Wed, 26 Aug 2026 18:03:19 +0900 From: Dominique Martinet To: Miquel Raynal Cc: Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] mtd: spinand: winbond: enable continuous read for W25N04LW Message-ID: References: <20260814-w25n04lw-contread-v1-1-2968b07c962d@atmark-techno.com> <871pbmk1ma.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <871pbmk1ma.fsf@bootlin.com> Miquel Raynal wrote on Tue, Aug 25, 2026 at 11:09:33AM +0200: > > Unfortunately on my system (i.MX 8ULP LPSPI) the first time continuous > > read is used spinand_read_from_cache_op() falls into this if and > > disables continuous read, so this didn't go any further: > > Ah, too bad :-) Yeah, I'll try to take some time to dig into the SPI driver to see if that can be fixed in software but I'm afraid it'll take a while longer... > > Fun fact: > > nanddump -C is about 9% faster than nanddump on large data (tried 10MB) > > even if continuous read is not supported. > > That is strange. Is this really reproducible? Can you disable CPU PM and > try again? There should be no impact if continuous read is disabled. This system has no knob that I'm aware of (no cpufreq in /sys/devices/system/cpu at least), but I've shoved the IRQs aside except for the spi ones and it appears pretty stable (mtd1 is a 8MB partition) ------ localhost:/mnt/mtd-utils# taskset -c 1 hyperfine --warmup 3 -r 20 './nanddump -f /dev/null /dev/mtd1' './nanddump -C - f /dev/null /dev/mtd1' Benchmark 1: ./nanddump -f /dev/null /dev/mtd1 Time (mean ± σ): 511.1 ms ± 0.5 ms [User: 7.8 ms, System: 419.8 ms] Range (min … max): 510.4 ms … 512.0 ms 20 runs Benchmark 2: ./nanddump -C -f /dev/null /dev/mtd1 Time (mean ± σ): 480.9 ms ± 0.9 ms [User: 0.5 ms, System: 399.6 ms] Range (min … max): 480.1 ms … 483.3 ms 20 runs Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options. Summary ./nanddump -C -f /dev/null /dev/mtd1 ran 1.06 ± 0.00 times faster than ./nanddump -f /dev/null /dev/mtd1 ------ (this is on our 6.12 tree and not on the 7.2-rc I was on earlier, so ymmv, but iirc the 9% figure was taken on 7.2 with hyperfine so this should be reproducible with the latest and greatest) I have much more important things to do so I obviously had to look further into this mystery :-), but I didn't see anything obvious... For some reason the contiguous read variant seems to spend less time in spinand_wait() between the load page and read from cache op (looking at a flamegraph), but dumping the actual ops used I see very similar sequences of load page (0x13), poll status (0xf), dirmap_read (0xeb), so that doesn't explain the difference... The main difference I see is that nanddump -C passes a much larger buffer to read (observable with strace -c), so loops for reading inside the kernel, and without -C loops in userspace: I do not see the syscall overhead in my perf record flamegraph but perhaps that changes the timing just enough for the nand to behave differently or something like that? Definitely curious, but I'm not sure if there's anything to act on here.. Cheers, -- Dominique