| Message ID | 20190201073613.14656-1-rosenp@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [OpenWrt-Devel] ramips: Increase GB-PC2 SPI speed to 50MHz | expand |
On Friday, February 1, 2019 8:36:13 AM CET Rosen Penev wrote: > The flash chip on the board (Spansion S25FL256SAIF00) is rated to support > at least 50MHz according to the datasheet. > > From testing this, that seems correct. > > time dd if=/dev/mtdblock3 of=/dev/null bs=64k from > > 41.78s to 16.61s > > Signed-off-by: Rosen Penev <rosenp@gmail.com> Hm, this is fine. There's just a small caveat. The mt7621-spi [0] can do at most (SYS_CLOCK) / 2 which works out as 50 MHz / 2 = 25 MHz and this is supported by your results as well: Because 41.78s / 16.61s = 2.51. If the spi-transfers were operating at 50 Mhz, dd would have taken just around 8-9 seconds. The reason why the dts patch this is still fine is because the spi-max-frequency's value is supposed to be taken from the slave device (S25FL256SAIF00 datasheet). So maybe, you could just mention in the commit message that speed it sadly capped at 25 Mhz. (Maybe you could also test, if you get better read performance by adding the "m25p,fast-read;" property [1] to the device's dts) Regards, Christian [0] <https://github.com/torvalds/linux/blob/master/drivers/staging/mt7621-spi/spi-mt7621.c#L304> [1] <https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/jedec%2Cspi-nor.txt> > --- > target/linux/ramips/dts/GB-PC2.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ramips/dts/GB-PC2.dts b/target/linux/ramips/dts/GB-PC2.dts > index 788d4e6c08..f951083b8f 100644 > --- a/target/linux/ramips/dts/GB-PC2.dts > +++ b/target/linux/ramips/dts/GB-PC2.dts > @@ -81,7 +81,7 @@ > m25p80@0 { > compatible = "jedec,spi-nor"; > reg = <0>; > - spi-max-frequency = <10000000>; > + spi-max-frequency = <50000000>; > > partitions { > compatible = "fixed-partitions"; >
On Sun, Feb 10, 2019 at 9:23 AM Christian Lamparter <chunkeey@gmail.com> wrote: > > On Friday, February 1, 2019 8:36:13 AM CET Rosen Penev wrote: > > The flash chip on the board (Spansion S25FL256SAIF00) is rated to support > > at least 50MHz according to the datasheet. > > > > From testing this, that seems correct. > > > > time dd if=/dev/mtdblock3 of=/dev/null bs=64k from > > > > 41.78s to 16.61s > > > > Signed-off-by: Rosen Penev <rosenp@gmail.com> > > Hm, this is fine. There's just a small caveat. The mt7621-spi [0] > can do at most (SYS_CLOCK) / 2 which works out as 50 MHz / 2 = 25 MHz > and this is supported by your results as well: > > Because 41.78s / 16.61s = 2.51. If the spi-transfers were operating > at 50 Mhz, dd would have taken just around 8-9 seconds. After applying the upstream spi driver ( https://github.com/openwrt/openwrt/pull/1578 ), time goes down to 9.54s on the PC1. It's a little lower on the PC2 (no idea why). On the PC1, I can go even higher with the SPI frequency to get better performance. However, the later versions of the PC1 switched flash chips to Spansion to avoid a restart bug. Those are documented as accepting 50MHz for read requests. > > The reason why the dts patch this is still fine is because the > spi-max-frequency's value is supposed to be taken from the slave > device (S25FL256SAIF00 datasheet). So maybe, you could just mention in the > commit message that speed it sadly capped at 25 Mhz. > > (Maybe you could also test, if you get better read performance > by adding the "m25p,fast-read;" property [1] to the device's dts) > > Regards, > Christian > > [0] <https://github.com/torvalds/linux/blob/master/drivers/staging/mt7621-spi/spi-mt7621.c#L304> > [1] <https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/jedec%2Cspi-nor.txt> > > --- > > target/linux/ramips/dts/GB-PC2.dts | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/target/linux/ramips/dts/GB-PC2.dts b/target/linux/ramips/dts/GB-PC2.dts > > index 788d4e6c08..f951083b8f 100644 > > --- a/target/linux/ramips/dts/GB-PC2.dts > > +++ b/target/linux/ramips/dts/GB-PC2.dts > > @@ -81,7 +81,7 @@ > > m25p80@0 { > > compatible = "jedec,spi-nor"; > > reg = <0>; > > - spi-max-frequency = <10000000>; > > + spi-max-frequency = <50000000>; > > > > partitions { > > compatible = "fixed-partitions"; > > > > > >
On Sun, Feb 10, 2019 at 9:23 AM Christian Lamparter <chunkeey@gmail.com> wrote: > > On Friday, February 1, 2019 8:36:13 AM CET Rosen Penev wrote: > > The flash chip on the board (Spansion S25FL256SAIF00) is rated to support > > at least 50MHz according to the datasheet. > > > > From testing this, that seems correct. > > > > time dd if=/dev/mtdblock3 of=/dev/null bs=64k from > > > > 41.78s to 16.61s > > > > Signed-off-by: Rosen Penev <rosenp@gmail.com> > > Hm, this is fine. There's just a small caveat. The mt7621-spi [0] > can do at most (SYS_CLOCK) / 2 which works out as 50 MHz / 2 = 25 MHz > and this is supported by your results as well: Forgot to mention. since hackpascal's rework of the CPU clock handling, SPI clock is not tied to sysclock anymore. sysclock is set to either 50MHz or 125MHz depending on the board. See: https://github.com/openwrt/openwrt/pull/1578#issuecomment-443676217 Also forgot to mention, those results are with the driver in OpenWrt. They're better with the upstream one. > > Because 41.78s / 16.61s = 2.51. If the spi-transfers were operating > at 50 Mhz, dd would have taken just around 8-9 seconds. > > The reason why the dts patch this is still fine is because the > spi-max-frequency's value is supposed to be taken from the slave > device (S25FL256SAIF00 datasheet). So maybe, you could just mention in the > commit message that speed it sadly capped at 25 Mhz. Should I? There are other mt7621 with dts files that exceed this figure. > > (Maybe you could also test, if you get better read performance > by adding the "m25p,fast-read;" property [1] to the device's dts) > > Regards, > Christian > > [0] <https://github.com/torvalds/linux/blob/master/drivers/staging/mt7621-spi/spi-mt7621.c#L304> > [1] <https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/jedec%2Cspi-nor.txt> > > --- > > target/linux/ramips/dts/GB-PC2.dts | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/target/linux/ramips/dts/GB-PC2.dts b/target/linux/ramips/dts/GB-PC2.dts > > index 788d4e6c08..f951083b8f 100644 > > --- a/target/linux/ramips/dts/GB-PC2.dts > > +++ b/target/linux/ramips/dts/GB-PC2.dts > > @@ -81,7 +81,7 @@ > > m25p80@0 { > > compatible = "jedec,spi-nor"; > > reg = <0>; > > - spi-max-frequency = <10000000>; > > + spi-max-frequency = <50000000>; > > > > partitions { > > compatible = "fixed-partitions"; > > > > > >
Hi! On Mon, Feb 11, 2019 at 7:49 AM Rosen Penev <rosenp@gmail.com> wrote: > [...] > On the PC1, I can go even higher with the SPI frequency to get better > performance. However, the later versions of the PC1 switched flash > chips to Spansion to avoid a restart bug. Those are documented as > accepting 50MHz for read requests. FYI: I haven't check the Spansion datasheet, but when Winbond datasheets say read instruction accepts SPI clock up to 50MHz it refers to the normal read instruction (0x03) and for higher clock you should switch to fast read instruction (0x0B) which can be done by adding m25p,fast-read to dts. I guess the situation with Spansion datasheets are the same.
On Sun, Feb 10, 2019 at 8:59 PM Chuanhong Guo <gch981213@gmail.com> wrote: > > Hi! > On Mon, Feb 11, 2019 at 7:49 AM Rosen Penev <rosenp@gmail.com> wrote: > > [...] > > On the PC1, I can go even higher with the SPI frequency to get better > > performance. However, the later versions of the PC1 switched flash > > chips to Spansion to avoid a restart bug. Those are documented as > > accepting 50MHz for read requests. > > FYI: I haven't check the Spansion datasheet, but when Winbond > datasheets say read instruction accepts SPI clock up to 50MHz it > refers to the normal read instruction (0x03) and for higher clock you > should switch to fast read instruction (0x0B) which can be done by > adding m25p,fast-read to dts. I guess the situation with Spansion > datasheets are the same. Wow, thanks for that fast read hint. According to a datasheet I found online, it accepts 50MHz for normal reads and 133MHz for fast reads. I then increased the speed to 80MHz and ran again: time dd if=/dev/mtdblock3 of=/dev/null = 6.15s 44.854483 seconds for jffs2 to complete building. I then increased to 104MHz time dd if=/dev/mtdblock3 of=/dev/null = 6.23s 44.312618 seconds for jffs2 to complete building 108MHz: time dd if=/dev/mtdblock3 of=/dev/null = 6.28s 44.501574 seconds for jffs2 to complete building I went back down to 50MHz just to make sure. time dd if=/dev/mtdblock3 of=/dev/null = 8.68s 46.344117 seconds for jffs2 to complete building then to 60MHz: time dd if=/dev/mtdblock3 of=/dev/null = 7.37s 46.172334 seconds for jffs2 to complete building and finally 66MHz: time dd if=/dev/mtdblock3 of=/dev/null 45.501151 seconds for jffs2 to complete building 133MHz and 125MHz did not work. The datasheet mentions 66MHz for mismatching core and I/O voltage and 133MHz for matching. 80MHz is still faster though...
diff --git a/target/linux/ramips/dts/GB-PC2.dts b/target/linux/ramips/dts/GB-PC2.dts index 788d4e6c08..f951083b8f 100644 --- a/target/linux/ramips/dts/GB-PC2.dts +++ b/target/linux/ramips/dts/GB-PC2.dts @@ -81,7 +81,7 @@ m25p80@0 { compatible = "jedec,spi-nor"; reg = <0>; - spi-max-frequency = <10000000>; + spi-max-frequency = <50000000>; partitions { compatible = "fixed-partitions";
The flash chip on the board (Spansion S25FL256SAIF00) is rated to support at least 50MHz according to the datasheet. From testing this, that seems correct. time dd if=/dev/mtdblock3 of=/dev/null bs=64k from 41.78s to 16.61s Signed-off-by: Rosen Penev <rosenp@gmail.com> --- target/linux/ramips/dts/GB-PC2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)