This patchset adds support for optional memory-mapped flash reading.
BTW: This controller is a ridiculous one which only supports very limited
spi-nor instructions. I can't rework the driver into a spi-mem one because
MTK didn't provide register description in their datasheet and even if they
do provide the documentation, the resulted driver will still be ridiculous
because it'll need to check every supported instructions in support_op and
do execution in one-by-one case in exec_op.
Chuanhong Guo (2):
mtd: mtk-quadspi: add support for memory-mapped flash reading
dt-bindings: mtd: mtk-quadspi: update bindings for mmap flash read
.../devicetree/bindings/mtd/mtk-quadspi.txt | 21 ++++++++++++++++++-
drivers/mtd/spi-nor/mtk-quadspi.c | 11 ++++++++++
2 files changed, 31 insertions(+), 1 deletion(-)
--
2.21.0
PIO reading mode on this controller is ridiculously inefficient
(one cmd+addr+dummy sequence reads only one byte)
This patch adds support for reading from memory-mapped flash area
which increases reading speed from 1MB/s to 5.6MB/s
Signed-off-by: Chuanhong Guo <[email protected]>
---
drivers/mtd/spi-nor/mtk-quadspi.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
index 34db01ab6cab..ba8b3be39896 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -106,6 +106,7 @@ struct mtk_nor {
struct spi_nor nor;
struct device *dev;
void __iomem *base; /* nor flash base address */
+ void __iomem *flash_base;
struct clk *spi_clk;
struct clk *nor_clk;
};
@@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
mtk_nor_set_read_mode(mtk_nor);
mtk_nor_set_addr(mtk_nor, addr);
+ if (mtk_nor->flash_base) {
+ memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
+ return length;
+ }
+
for (i = 0; i < length; i++) {
ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
if (ret < 0)
@@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
if (IS_ERR(mtk_nor->base))
return PTR_ERR(mtk_nor->base);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mtk_nor->flash_base))
+ mtk_nor->flash_base = NULL;
+
mtk_nor->spi_clk = devm_clk_get(&pdev->dev, "spi");
if (IS_ERR(mtk_nor->spi_clk))
return PTR_ERR(mtk_nor->spi_clk);
--
2.21.0
update register descriptions and add an example binding using it.
Signed-off-by: Chuanhong Guo <[email protected]>
---
.../devicetree/bindings/mtd/mtk-quadspi.txt | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
index a12e3b5c495d..4860f6e96f5a 100644
--- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
@@ -12,7 +12,10 @@ Required properties:
"mediatek,mt7623-nor", "mediatek,mt8173-nor"
"mediatek,mt7629-nor", "mediatek,mt8173-nor"
"mediatek,mt8173-nor"
-- reg: physical base address and length of the controller's register
+- reg: Contains one or two entries, each of which is a tuple consisting of a
+ physical address and length. The first entry is the address and length
+ of the controller register set. The optional second entry is the address
+ and length of the area where the nor flash is mapped to.
- clocks: the phandle of the clocks needed by the nor controller
- clock-names: the names of the clocks
the clocks should be named "spi" and "sf". "spi" is used for spi bus,
@@ -48,3 +51,19 @@ nor_flash: spi@1100d000 {
};
};
+nor_flash: spi@11014000 {
+ compatible = "mediatek,mt7629-nor",
+ "mediatek,mt8173-nor";
+ reg = <0x11014000 0xe0>,
+ <0x30000000 0x10000000>;
+ clocks = <&pericfg CLK_PERI_FLASH_PD>,
+ <&topckgen CLK_TOP_FLASH_SEL>;
+ clock-names = "spi", "sf";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+};
--
2.21.0
On Wed, Nov 06, 2019 at 10:07:48PM +0800, Chuanhong Guo wrote:
> update register descriptions and add an example binding using it.
>
> Signed-off-by: Chuanhong Guo <[email protected]>
> ---
> .../devicetree/bindings/mtd/mtk-quadspi.txt | 21 ++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> index a12e3b5c495d..4860f6e96f5a 100644
> --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> @@ -12,7 +12,10 @@ Required properties:
> "mediatek,mt7623-nor", "mediatek,mt8173-nor"
> "mediatek,mt7629-nor", "mediatek,mt8173-nor"
> "mediatek,mt8173-nor"
> -- reg: physical base address and length of the controller's register
> +- reg: Contains one or two entries, each of which is a tuple consisting of a
> + physical address and length. The first entry is the address and length
> + of the controller register set. The optional second entry is the address
> + and length of the area where the nor flash is mapped to.
All the compatibles support 2 entries? If not, which ones?
> - clocks: the phandle of the clocks needed by the nor controller
> - clock-names: the names of the clocks
> the clocks should be named "spi" and "sf". "spi" is used for spi bus,
> @@ -48,3 +51,19 @@ nor_flash: spi@1100d000 {
> };
> };
>
> +nor_flash: spi@11014000 {
> + compatible = "mediatek,mt7629-nor",
> + "mediatek,mt8173-nor";
> + reg = <0x11014000 0xe0>,
> + <0x30000000 0x10000000>;
> + clocks = <&pericfg CLK_PERI_FLASH_PD>,
> + <&topckgen CLK_TOP_FLASH_SEL>;
> + clock-names = "spi", "sf";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + };
> +};
> --
> 2.21.0
>
Hi,
On 06/11/19 7:37 PM, Chuanhong Guo wrote:
> PIO reading mode on this controller is ridiculously inefficient
> (one cmd+addr+dummy sequence reads only one byte)
> This patch adds support for reading from memory-mapped flash area
> which increases reading speed from 1MB/s to 5.6MB/s
>
> Signed-off-by: Chuanhong Guo <[email protected]>
> ---
> drivers/mtd/spi-nor/mtk-quadspi.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> index 34db01ab6cab..ba8b3be39896 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -106,6 +106,7 @@ struct mtk_nor {
> struct spi_nor nor;
> struct device *dev;
> void __iomem *base; /* nor flash base address */
> + void __iomem *flash_base;
> struct clk *spi_clk;
> struct clk *nor_clk;
> };
> @@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
> mtk_nor_set_read_mode(mtk_nor);
> mtk_nor_set_addr(mtk_nor, addr);
>
> + if (mtk_nor->flash_base) {
> + memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
> + return length;
> + }
> +
Don't you need to check if access is still within valid memory mapped
window?
> for (i = 0; i < length; i++) {
> ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
> if (ret < 0)
> @@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
> if (IS_ERR(mtk_nor->base))
> return PTR_ERR(mtk_nor->base);
>
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
There is a single API now: devm_platform_ioremap_resource().
> + if (IS_ERR(mtk_nor->flash_base))
> + mtk_nor->flash_base = NULL;
> +
> mtk_nor->spi_clk = devm_clk_get(&pdev->dev, "spi");
> if (IS_ERR(mtk_nor->spi_clk))
> return PTR_ERR(mtk_nor->spi_clk);
>
--
Regards
Vignesh
Hi!
On Thu, Nov 7, 2019 at 9:09 AM Rob Herring <[email protected]> wrote:
>
> On Wed, Nov 06, 2019 at 10:07:48PM +0800, Chuanhong Guo wrote:
> > update register descriptions and add an example binding using it.
> >
> > Signed-off-by: Chuanhong Guo <[email protected]>
> > ---
> > .../devicetree/bindings/mtd/mtk-quadspi.txt | 21 ++++++++++++++++++-
> > 1 file changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > index a12e3b5c495d..4860f6e96f5a 100644
> > --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > @@ -12,7 +12,10 @@ Required properties:
> > "mediatek,mt7623-nor", "mediatek,mt8173-nor"
> > "mediatek,mt7629-nor", "mediatek,mt8173-nor"
> > "mediatek,mt8173-nor"
> > -- reg: physical base address and length of the controller's register
> > +- reg: Contains one or two entries, each of which is a tuple consisting of a
> > + physical address and length. The first entry is the address and length
> > + of the controller register set. The optional second entry is the address
> > + and length of the area where the nor flash is mapped to.
>
> All the compatibles support 2 entries? If not, which ones?
It should be. I implemented it as an optional feature only because I
don't know the mapped address space for all these chips and can't
update every device trees.
Regards,
Chuanhong Guo
Hi!
On Thu, Nov 7, 2019 at 2:05 PM Vignesh Raghavendra <[email protected]> wrote:
> > @@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
> > mtk_nor_set_read_mode(mtk_nor);
> > mtk_nor_set_addr(mtk_nor, addr);
> >
> > + if (mtk_nor->flash_base) {
> > + memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
> > + return length;
> > + }
> > +
>
> Don't you need to check if access is still within valid memory mapped
> window?
The mapped area is 256MB and I don't quite believe there will be such
a big NOR flash.
I'll add a check here in the next version.
>
> > for (i = 0; i < length; i++) {
> > ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
> > if (ret < 0)
> > @@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
> > if (IS_ERR(mtk_nor->base))
> > return PTR_ERR(mtk_nor->base);
> >
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
>
> There is a single API now: devm_platform_ioremap_resource().
Cool. I'll change it.
Should I add another patch to change the same mapping operation right
above this piece of code?
Regards,
Chuanhong Guo
On 07/11/19 3:01 PM, Chuanhong Guo wrote:
> Hi!
>
> On Thu, Nov 7, 2019 at 2:05 PM Vignesh Raghavendra <[email protected]> wrote:
>>> @@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
>>> mtk_nor_set_read_mode(mtk_nor);
>>> mtk_nor_set_addr(mtk_nor, addr);
>>>
>>> + if (mtk_nor->flash_base) {
>>> + memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
>>> + return length;
>>> + }
>>> +
>>
>> Don't you need to check if access is still within valid memory mapped
>> window?
>
> The mapped area is 256MB and I don't quite believe there will be such
> a big NOR flash.
> I'll add a check here in the next version.
>
There are 256MB (2GiB) NORs out there in market already. So, pretty
soon, 256MB window won't be big enough :)
>>
>>> for (i = 0; i < length; i++) {
>>> ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
>>> if (ret < 0)
>>> @@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
>>> if (IS_ERR(mtk_nor->base))
>>> return PTR_ERR(mtk_nor->base);
>>>
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> + mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
>>
>> There is a single API now: devm_platform_ioremap_resource().
>
> Cool. I'll change it.
> Should I add another patch to change the same mapping operation right
> above this piece of code?
>
That would be nice to do too, please send a separate patch.
--
Regards
Vignesh
On Wed, 2019-11-06 at 22:07 +0800, Chuanhong Guo wrote:
> PIO reading mode on this controller is ridiculously inefficient
> (one cmd+addr+dummy sequence reads only one byte)
> This patch adds support for reading from memory-mapped flash area
> which increases reading speed from 1MB/s to 5.6MB/s
This may not be true for all MTK SoC. Which one are you testing?
Joe.C
Hi!
On Thu, Nov 7, 2019 at 9:23 PM Yingjoe Chen <[email protected]> wrote:
>
> On Wed, 2019-11-06 at 22:07 +0800, Chuanhong Guo wrote:
> > PIO reading mode on this controller is ridiculously inefficient
> > (one cmd+addr+dummy sequence reads only one byte)
> > This patch adds support for reading from memory-mapped flash area
> > which increases reading speed from 1MB/s to 5.6MB/s
>
> This may not be true for all MTK SoC. Which one are you testing?
>
I tested it on MT7629.
There should be a 5x reading speed increment under DMA or direct read
mode than PIO mode because PIO mode needs 30 or 36 clocks for every
single byte of data while DMA or direct read only needs 24 or 30
clocks for initial command/address/dummy and every byte of data after
that only need 8 clocks.
Regards,
Chuanhong Guo
Hi!
On Wed, Nov 6, 2019 at 10:08 PM Chuanhong Guo <[email protected]> wrote:
>
> update register descriptions and add an example binding using it.
>
> Signed-off-by: Chuanhong Guo <[email protected]>
I'll abandon this patchset and implement DMA reading instead.
Regards,
Chuanhong Guo
Hi all!
On Wed, Nov 6, 2019 at 10:08 PM Chuanhong Guo <[email protected]> wrote:
>
> PIO reading mode on this controller is ridiculously inefficient
> (one cmd+addr+dummy sequence reads only one byte)
> This patch adds support for reading from memory-mapped flash area
> which increases reading speed from 1MB/s to 5.6MB/s
>
> Signed-off-by: Chuanhong Guo <[email protected]>
> ---
> drivers/mtd/spi-nor/mtk-quadspi.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
I'll abandon this patchset and implement DMA reading instead.
Regards,
Chuanhong Guo