Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934827AbbGVQ7a (ORCPT ); Wed, 22 Jul 2015 12:59:30 -0400 Received: from eusmtp01.atmel.com ([212.144.249.242]:45649 "EHLO eusmtp01.atmel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932752AbbGVQ71 (ORCPT ); Wed, 22 Jul 2015 12:59:27 -0400 Message-ID: <55AFCBE9.2030700@atmel.com> Date: Wed, 22 Jul 2015 18:59:21 +0200 From: Cyrille Pitchen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Marek Vasut CC: , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 2/5] Documentation: mtd: add a DT property to set the number of dummy cycles References: <8119e3b46b91e43c10466b2400c6938a113b1c02.1437569902.git.cyrille.pitchen@atmel.com> <201507221543.54761.marex@denx.de> In-Reply-To: <201507221543.54761.marex@denx.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.161.30.18] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3654 Lines: 74 Hi Marek, Le 22/07/2015 15:43, Marek Vasut a ?crit : > On Wednesday, July 22, 2015 at 03:17:07 PM, Cyrille Pitchen wrote: >> Depending on the SPI clock frequency, the Fast Read op code and the >> Single/Dual Data Rate mode, the number of dummy cycles can be tuned to >> improve transfer speed. >> The actual number of dummy cycles is specific for each memory model and is >> provided by the manufacturer thanks to the memory datasheet. >> >> Signed-off-by: Cyrille Pitchen >> --- >> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt >> b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index >> 2bee68103b01..4387567d8024 100644 >> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt >> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt >> @@ -19,6 +19,11 @@ Optional properties: >> all chips and support for it can not be detected at >> runtime. Refer to your chips' datasheet to check if this is supported by >> your chip. >> +- m25p,num-dummy-cycles : Set the number of dummy cycles for Fast Read >> commands. + Depending on the manufacturer >> additional dedicated + commands are sent to the >> flash memory so the + controller and the memory >> can agree on the number of + dummy cycles to use. > > Can't you just try negotiating this value at probe time, starting with some > high value and see how low you can get with the negotiations ? This way, you'd > be able to effectively auto-detect this value at probe-time. > > I might be wrong though :) > I don't know whether it would be reliable enough. It is the exact same idea as for the latency code used by Spansion QSPI memories. Micron memories allow to skip the step of converting the number of dummy cycles into a latency code, you directly program the right number of dummy cycles into a Micron specific register, the Volatile Configuration Register. However for both manufacturers the number of dummy cycles to use during Fast Read commands is given though tables found into the memory datasheet. The number of dummy cycles depends on the Fast Read command, the SPI bus clock frequency and the Single/Dual Data Rate mode. It should be confirmed by Quad SPI memory manufacturers but since the number of dummy cycles depends on the bus clock frequency, I guess the values provided by the datasheets are recommendations. I think a too low value should not be so easy to detect. For a given frequency one Fast Read command may succeed whereas the same command with the very same number of dummy cycles might fail on the next try. To be honest, I'm not sure about the memory behavior in limit conditions so maybe the command will always succeed or always fail. Also we can't be sure the read data are valid if we don't write them first. So we would have to save the original data to restore them at the end of the probing. Writing data at each probe would also reduce the memory lifetime. We should also be aware of the bad blocks, which is more a job for upper layers. It would be interesting to have some feedbacks from Micron, Spansion or other QSPI memory manufacturer :) > Best regards, > Marek Vasut > Best regards, Cyrille -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/