From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3BC801487D5 for ; Wed, 29 Jan 2025 15:39:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738165163; cv=none; b=t19JUhcZNRb2WUamA2C0k38JjATiFtV79MwXFvfKsY4JOaHopgE4KjiJdNxv3hxNJSNJvR+qH/JIo/97PceZqTUjKUs4zh9bFq2kPFzcQasQTeYJ0qun+uLPHui1ECYrWQQz/C74/cdc2COhnvIsOYJom5c5UQaVwXjl8ZUVlxQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738165163; c=relaxed/simple; bh=d43wTg1xnHR5CahqpdWTCRzF2l/LHrbFnCssNqyFVDQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=o/7yiIxOSQ6pQJDRqR0IWIi7uV7pncnDgkw03FoBRipzOwtV3g9L71XZ9VfbqW9c1Z+JsaqLnOjybMbjiKCCyD2FJ9sIduFuNENAh0MhnEP9S2OYzt3kPpErAC3PewsodLEETS4roDyQrT0IGmRRaJzwlCfkWbaoqFo/O6JL/tU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B+TO1bxT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B+TO1bxT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D45BC4CED1; Wed, 29 Jan 2025 15:39:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738165162; bh=d43wTg1xnHR5CahqpdWTCRzF2l/LHrbFnCssNqyFVDQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=B+TO1bxTFq1qC1R8rmuIU2k8AcLS/uBKhnr99ZMItwQOXceXmiUuCCJ3PAqqW3Lg1 9qrtu+HjAtinLCXk2H+B6nOQ0piNPjxLN5im6hPwFeeOlrUi4L0SMvdKGt4XjICP7G 7AFHFJcEV+sqj6NONqKZi6nC3mConI/YcyknpA+vbXx9y2ZD61rgr6ve9lK1J7YTHz mZTJLW73Tt8pIyhk92468ElcvuubV0IXmgsBA1tdoZ/O8u6EW+Zy7gzHgHp31pOa+d TDW6HsABNpM/eodaBWFWSlvpca81caeoRCE9mA1LRoQn3b96p4T+vUItli3DgXK8VG mVHyzYAnbTRNw== From: Pratyush Yadav To: Miquel Raynal Cc: Tudor Ambarus , Pratyush Yadav , Michael Walle , Richard Weinberger , Vignesh Raghavendra , Thomas Petazzoni , Steam Lin , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] mtd: spi-nor: winbond: Add support for w25q01jv In-Reply-To: <20250110-winbond-6-12-rc1-nor-volatile-bit-v3-1-735363f8cc7d@bootlin.com> (Miquel Raynal's message of "Fri, 10 Jan 2025 15:49:30 +0100") References: <20250110-winbond-6-12-rc1-nor-volatile-bit-v3-0-735363f8cc7d@bootlin.com> <20250110-winbond-6-12-rc1-nor-volatile-bit-v3-1-735363f8cc7d@bootlin.com> Date: Wed, 29 Jan 2025 15:39:19 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Jan 10 2025, Miquel Raynal wrote: > Add support for Winbond w25q01jv spi-nor chip. > > This chip is internally made of two dies with linear addressing > capabilities to make it transparent to the user that two dies were > used. There is one drawback however, the read status operation is racy > as the status bit only gives the active die status and not the status of > the other die. For commands affecting the two dies, it means if another > command is sent too fast after the first die has returned a valid status > (deviation can be up to 200us), the chip will get corrupted/in an > unstable state. > > This chip hence requires a better status register read. There are three > solutions here: > > 1- If we assume that the most common situation producing this problem is > status register writes, maybe we could change the "non-volatile" > status register write commands to become "volatile" status register > writes. In practice, what takes time is the write operation of the bits > themselves, and not the activation of the feature in the internal > circuitry. Enabling "volatile" status register writes would make the > writes nearly instant. > > This approach, besides probably being the less impacting one, could > overlook other possible actions where both dies can be used at the same > time like a chip erase (or any erase over die boundaries in general). > > 2- Wait about 200us after getting a first status ready feedback. This > 200us is about the maximum possible deviation between dies and would > cover all cases. > > 3- We iterate manually over all internal dies (which takes about 30us > per die) until all are ready. This approach will always be faster than > a blind delay which represents the maximum deviation, while also being > totally safe. > > This third approach has been adopted. A flash-specific hook for the > status register read had to be implemented. Testing with the flash_speed > benchmark shown no difference with the existing performances (using the > regular status read core function). In practice there are difference in > the experimental results below, but they are part of the natural > deviation of the benchmark: > > > Without the fixup > $ flash_speed /dev/mtd0 -c100 -d > eraseblock write speed is 442 KiB/s > eraseblock read speed is 1606 KiB/s > page write speed is 439 KiB/s > page read speed is 1520 KiB/s > 2 page write speed is 441 KiB/s > 2 page read speed is 1562 KiB/s > erase speed is 68 KiB/s > > > With the fixup > $ flash_speed /dev/mtd0 -c100 -d > eraseblock write speed is 428 KiB/s > eraseblock read speed is 1626 KiB/s > page write speed is 426 KiB/s > page read speed is 1538 KiB/s > 2 page write speed is 426 KiB/s > 2 page read speed is 1574 KiB/s > erase speed is 66 KiB/s > > However, the fixup, whatever which one we pick, must be applied on > multi-die chips, which hence must be properly flagged. The SFDP tables > implemented give a lot of information but the die details are part of an > optional table that is not implemented, hence we use a post parsing > fixup hook to set the params->n_dice value manually. > > Link: https://www.winbond.com/resource-files/W25Q01JV%20SPI%20RevE%2003042024%20Plus.pdf > Signed-off-by: Miquel Raynal Reviewed-by: Pratyush Yadav -- Regards, Pratyush Yadav