From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyrille Pitchen Subject: Re: [PATCH v2 2/5] Documentation: mtd: add a DT property to set the number of dummy cycles Date: Wed, 22 Jul 2015 18:59:21 +0200 Message-ID: <55AFCBE9.2030700@atmel.com> References: <8119e3b46b91e43c10466b2400c6938a113b1c02.1437569902.git.cyrille.pitchen@atmel.com> <201507221543.54761.marex@denx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <201507221543.54761.marex-ynQEQJNshbs@public.gmane.org> Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Marek Vasut Cc: nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org, broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org, juhosg-p3rKhJxN3npAfugRpC6u6w@public.gmane.org, shijie.huang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org Hi Marek, Le 22/07/2015 15:43, Marek Vasut a =E9crit : > 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 supporte= d by >> your chip. >> +- m25p,num-dummy-cycles : Set the number of dummy cycles for Fast R= ead >> commands. + Depending on the manufacturer >> additional dedicated + commands are sent to= the >> flash memory so the + controller and the me= mory >> can agree on the number of + dummy cycles t= o use. >=20 > Can't you just try negotiating this value at probe time, starting wit= h some > high value and see how low you can get with the negotiations ? This w= ay, you'd=20 > be able to effectively auto-detect this value at probe-time. >=20 > I might be wrong though :) >=20 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 al= low to skip the step of converting the number of dummy cycles into a latency c= ode, you directly program the right number of dummy cycles into a Micron specifi= c register, the Volatile Configuration Register. However for both manufacturers the number of dummy cycles to use during= Fast=20 Read commands is given though tables found into the memory datasheet. T= he number of dummy cycles depends on the Fast Read command, the SPI bus cl= ock frequency and the Single/Dual Data Rate mode. It should be confirmed by Quad SPI memory manufacturers but since the n= umber of dummy cycles depends on the bus clock frequency, I guess the values pro= vided 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 o= n 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 fi= rst. So we would have to save the original data to restore them at the end of t= he probing. Writing data at each probe would also reduce the memory lifeti= me. We should also be aware of the bad blocks, which is more a job for upper l= ayers. It would be interesting to have some feedbacks from Micron, Spansion or= other QSPI memory manufacturer :) > Best regards, > Marek Vasut >=20 Best regards, Cyrille -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html