Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver

[Marek Vasut]

On Thursday, August 20, 2015 at 08:55:05 AM, vn...@altera.com wrote:
> From: VIET NGA DAO <vn...@altera.com>
>
> Altera Quad SPI Controller is a soft IP which enables access to
> Altera EPCS and EPCQ flash chips. This patch adds driver
> for these devices.
>
> Signed-off-by: VIET NGA DAO <vn...@altera.com>
>
> ---
> v5:
> - Remove Micron support
> - Add multiple flashes probe failure handle
>
> v4:
> - Add more flash devices support ( EPCQL and Micron)
> - Remove redundant messages
> - Change EPCQ_OPCODE_ID to NON_EPCS_OPCODE_ID
> - Replace get_flash_name to altera_quadspi_scan
> - Remove clk related parts
> - Remove altera_quadspi_plat
> - Change device tree reg name and remove opcode-id
>
> v3:
> - Change altera_epcq driver name to altera_quadspi for more generic name
> - Implement flash name searching in altera_quadspi.c instead of spi-nor
> - Edit the altra quadspi info table in spi-nor
> - Remove wait_til_ready in all read,write, erase, lock, unlock functions
> - Merge .h and .c into 1 file
>
> v2:
> - Change to spi_nor structure
> - Add lock and unlock functions for spi_nor
> - Simplify the altera_epcq_lock function
> - Replace reg by compatible in device tree
> ---
> .../devicetree/bindings/mtd/altera-quadspi.txt | 45 ++
> drivers/mtd/spi-nor/Kconfig | 8 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/altera-quadspi.c | 557
> ++++++++++++++++++++ drivers/mtd/spi-nor/spi-nor.c |
> 18 +
> 5 files changed, 629 insertions(+), 0 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/mtd/altera-quadspi.txt create mode
> 100644 drivers/mtd/spi-nor/altera-quadspi.c
>
> diff --git a/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
> b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt new file mode
> 100644
> index 0000000..e1bcf18
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/altera-quadspi.txt
> @@ -0,0 +1,45 @@
> +* MTD Altera QUADSPI driver
> +
> +Required properties:
> +- compatible: Should be "altr,quadspi-1.0"
> +- reg: Address and length of the register set for the device. It contains
> + the information of registers in the same order as described by reg-names
> +- reg-names: Should contain the reg names
> + "avl_csr": Should contain the register configuration base address
> + "avl_mem": Should contain the data base address
> +- #address-cells: Must be <1>.
> +- #size-cells: Must be <0>.
> +- flash device tree subnode, there must be a node with the following
> fields: + - compatible: Should contain the flash name:
> + 1. EPCS: epcs16, epcs64, epcs128
> + 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512, epcq1024
> + 3. EPCQ-L: epcql256, epcql512, epcql1024
> + - #address-cells: please refer to /mtd/partition.txt
> + - #size-cells: please refer to /mtd/partition.txt
> + For partitions inside each flash, please refer to /mtd/partition.txt
> +
> +Example:
> +
> + quadspi_controller_0: quadspi@0x180014a0 {
> + compatible = "altr,quadspi-1.0";
> + reg = <0x180014a0 0x00000020>,
> + <0x14000000 0x04000000>;
> + reg-names = "avl_csr", "avl_mem";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + flash0: epcq256@0 {
> + compatible = "altr,epcq256";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + /* 16 MB for raw data. */
> + label = "EPCQ Flash 0 raw data";
> + reg = <0x0 0x1000000>;
> + };
> + partition@1000000 {
> + /* 16 MB for jffs2 data. */
> + label = "EPCQ Flash 0 JFFS 2";
> + reg = <0x1000000 0x1000000>;
> + };

IIRC, encoding partitions into OF is deprecated (and it shouldn't be
part of the example anyway, so please remove this bit).

> + };
> + }; //end quadspi@0x180014a0 (quadspi_controller_0)

Remove this incorrect comment.


[...]

> +static struct flash_device flash_devices[] = {
> + FLASH_ID("epcs16", EPCS_OPCODE_ID, 0x14),
> + FLASH_ID("epcs64", EPCS_OPCODE_ID, 0x16),
> + FLASH_ID("epcs128", EPCS_OPCODE_ID, 0x18),
> +
> + FLASH_ID("epcq16", NON_EPCS_OPCODE_ID, 0x15),
> + FLASH_ID("epcq32", NON_EPCS_OPCODE_ID, 0x16),
> + FLASH_ID("epcq64", NON_EPCS_OPCODE_ID, 0x17),
> + FLASH_ID("epcq128", NON_EPCS_OPCODE_ID, 0x18),
> + FLASH_ID("epcq256", NON_EPCS_OPCODE_ID, 0x19),
> + FLASH_ID("epcq512", NON_EPCS_OPCODE_ID, 0x20),
> + FLASH_ID("epcq1024", NON_EPCS_OPCODE_ID, 0x21),
> +
> + FLASH_ID("epcql256", NON_EPCS_OPCODE_ID, 0x19),
> + FLASH_ID("epcql512", NON_EPCS_OPCODE_ID, 0x20),
> + FLASH_ID("epcql1024", NON_EPCS_OPCODE_ID, 0x21),
> +
> +};

I think it'd be better to wait until the IP block is fixed and can
issue READID correctly.

> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 14a5d23..2ab7279 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -687,6 +687,24 @@ static const struct spi_device_id spi_nor_ids[] = {
> { "cat25c09", CAT25_INFO( 128, 8, 32, 2, SPI_NOR_NO_ERASE |
> SPI_NOR_NO_FR) }, { "cat25c17", CAT25_INFO( 256, 8, 32, 2,
> SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) }, { "cat25128", CAT25_INFO(2048, 8, 64,
> 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) }, +
> + /* Altera EPCQ/EPCS Flashes are non-JEDEC */

Are they really ? Last time I checked on CV SoC, I was able to read their
JEDEC ID just fine ; though it's true I used that EPCS core.

> + { "epcs16", INFO(0, 0, 0x10000, 32, 0) },
> + { "epcs64", INFO(0, 0, 0x10000, 128, 0) },
> + { "epcs128", INFO(0, 0, 0x40000, 256, 0) },
> +
> + { "epcq16", INFO(0, 0, 0x10000, 32, 0) },
> + { "epcq32", INFO(0, 0, 0x10000, 64, 0) },
> + { "epcq64", INFO(0, 0, 0x10000, 128, 0) },
> + { "epcq128", INFO(0, 0, 0x10000, 256, 0) },
> + { "epcq256", INFO(0, 0, 0x10000, 512, 0) },
> + { "epcq512", INFO(0, 0, 0x10000, 1024, 0) },
> + { "epcq1024", INFO(0, 0, 0x10000, 2048, 0) },
> +
> + { "epcql256", INFO(0, 0, 0x10000, 512, 0) },
> + { "epcql512", INFO(0, 0, 0x10000, 1024, 0) },
> + { "epcql1024", INFO(0, 0, 0x10000, 2048, 0) },
> +
> { },
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Nga Chi]

Do you mean the partition part below should not be in example?
partition@0 {

/* 16 MB for raw data. */

label = "EPCQ Flash 0 raw data";

reg = <0x0 0x1000000>;
};
partition@1000000 {

/* 16 MB for jffs2 data. */

label = "EPCQ Flash 0 JFFS 2";

reg = <0x1000000 0x1000000>;
};

>> +static struct flash_device flash_devices[] = {
>> + FLASH_ID("epcs16", EPCS_OPCODE_ID, 0x14),
>> + FLASH_ID("epcs64", EPCS_OPCODE_ID, 0x16),
>> + FLASH_ID("epcs128", EPCS_OPCODE_ID, 0x18),
>> +
>> + FLASH_ID("epcq16", NON_EPCS_OPCODE_ID, 0x15),
>> + FLASH_ID("epcq32", NON_EPCS_OPCODE_ID, 0x16),
>> + FLASH_ID("epcq64", NON_EPCS_OPCODE_ID, 0x17),
>> + FLASH_ID("epcq128", NON_EPCS_OPCODE_ID, 0x18),
>> + FLASH_ID("epcq256", NON_EPCS_OPCODE_ID, 0x19),
>> + FLASH_ID("epcq512", NON_EPCS_OPCODE_ID, 0x20),
>> + FLASH_ID("epcq1024", NON_EPCS_OPCODE_ID, 0x21),
>> +
>> + FLASH_ID("epcql256", NON_EPCS_OPCODE_ID, 0x19),
>> + FLASH_ID("epcql512", NON_EPCS_OPCODE_ID, 0x20),
>> + FLASH_ID("epcql1024", NON_EPCS_OPCODE_ID, 0x21),
>> +
>> +};
>
> I think it'd be better to wait until the IP block is fixed and can
> issue READID correctly.
>

The hardware IP fix will take time while there are lot of customer are
waiting for this driver. That is why we decided to upstream the
driver. If the hardware fix, there might not need to have any changes
in driver to support or if yes, it will be just minor.

Nga

[Viet Nga Dao]

Sorry for missing to reply the last question

Altera EPCS flash is non-jedec device. And this new controller is not
EPCS controller. If you look at the documentation i sent in another
email, they are not the same.

[Marek Vasut]

Yes, it's not really relevant.

> >> +static struct flash_device flash_devices[] = {
> >> + FLASH_ID("epcs16", EPCS_OPCODE_ID, 0x14),
> >> + FLASH_ID("epcs64", EPCS_OPCODE_ID, 0x16),
> >> + FLASH_ID("epcs128", EPCS_OPCODE_ID, 0x18),
> >> +
> >> + FLASH_ID("epcq16", NON_EPCS_OPCODE_ID, 0x15),
> >> + FLASH_ID("epcq32", NON_EPCS_OPCODE_ID, 0x16),
> >> + FLASH_ID("epcq64", NON_EPCS_OPCODE_ID, 0x17),
> >> + FLASH_ID("epcq128", NON_EPCS_OPCODE_ID, 0x18),
> >> + FLASH_ID("epcq256", NON_EPCS_OPCODE_ID, 0x19),
> >> + FLASH_ID("epcq512", NON_EPCS_OPCODE_ID, 0x20),
> >> + FLASH_ID("epcq1024", NON_EPCS_OPCODE_ID, 0x21),
> >> +
> >> + FLASH_ID("epcql256", NON_EPCS_OPCODE_ID, 0x19),
> >> + FLASH_ID("epcql512", NON_EPCS_OPCODE_ID, 0x20),
> >> + FLASH_ID("epcql1024", NON_EPCS_OPCODE_ID, 0x21),
> >> +
> >> +};
> >
> > I think it'd be better to wait until the IP block is fixed and can
> > issue READID correctly.
>
> The hardware IP fix will take time while there are lot of customer are
> waiting for this driver.

Does that justify pushing serious crap into mainline Linux in any way ?

> That is why we decided to upstream the
> driver. If the hardware fix, there might not need to have any changes
> in driver to support or if yes, it will be just minor.

If the hardware can do proper READID opcode, this entire nonsense table
will go away and a proper integration into the SPI NOR framework will
take place.

You might consider submitting this driver for staging, but I definitely
am not a big fan of that.

[Marek Vasut]

On Thursday, August 20, 2015 at 10:17:57 AM, Viet Nga Dao wrote:
> Sorry for missing to reply the last question

Hi!

> >>> diff --git a/drivers/mtd/spi-nor/spi-nor.c
> >>> b/drivers/mtd/spi-nor/spi-nor.c index 14a5d23..2ab7279 100644
> >>> --- a/drivers/mtd/spi-nor/spi-nor.c
> >>> +++ b/drivers/mtd/spi-nor/spi-nor.c
> >>> @@ -687,6 +687,24 @@ static const struct spi_device_id spi_nor_ids[] =
> >>> {
> >>>
> >>> { "cat25c09", CAT25_INFO( 128, 8, 32, 2, SPI_NOR_NO_ERASE |
> >>>
> >>> SPI_NOR_NO_FR) }, { "cat25c17", CAT25_INFO( 256, 8, 32, 2,
> >>> SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) }, { "cat25128", CAT25_INFO(2048, 8,
> >>> 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) }, +
> >>> + /* Altera EPCQ/EPCS Flashes are non-JEDEC */
> >>
> >> Are they really ? Last time I checked on CV SoC, I was able to read
> >> their JEDEC ID just fine ; though it's true I used that EPCS core.
>
> Altera EPCS flash is non-jedec device. And this new controller is not
> EPCS controller. If you look at the documentation i sent in another
> email, they are not the same.

https://www.altera.com/content/dam/altera-
www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf page 15 ; seems
like opcode 0x9f is supported. All the other opcodes seems compatible too.
What is the problem ?

Best regards,
Marek Vasut

[Viet Nga Dao]

OK

You might misunderstand the hardware problem i mention here. This soft
IP controller is able to provide the ID for our Altera EPCS/EPCQ flash
chips, which are non JEDEC chips. As from EPCQ device data sheet
(https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf),
the device ID is 8 bit data. The remaining problem here is that this
controller is able to support Micron chips but it currently has
limitation in providing only 8 bit ID, which is not full JEDEC ID for
Micron chips. Hence, we are asking hardware engineer to find out the
solution so that the driver does not need to do any dirty hacking. And
so, this table should still be here even hardware fix will take place
or not.

[Marek Vasut]

On Thursday, August 20, 2015 at 11:18:14 AM, Viet Nga Dao wrote:

Hi,

[...]

> >> That is why we decided to upstream the
> >> driver. If the hardware fix, there might not need to have any changes
> >> in driver to support or if yes, it will be just minor.
> >
> > If the hardware can do proper READID opcode, this entire nonsense table
> > will go away and a proper integration into the SPI NOR framework will
> > take place.
> >
> > You might consider submitting this driver for staging, but I definitely
> > am not a big fan of that.
>
> You might misunderstand the hardware problem i mention here. This soft
> IP controller is able to provide the ID for our Altera EPCS/EPCQ flash
> chips, which are non JEDEC chips. As from EPCQ device data sheet
> (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature
> /hb/cfg/cfg_cf52012.pdf), the device ID is 8 bit data.

So what exactly is the output of READID instruction followed by 6 Byte read
on an EPCQ chip?

> The remaining
> problem here is that this controller is able to support Micron chips but
> it currently has
> limitation in providing only 8 bit ID, which is not full JEDEC ID for
> Micron chips.

OK

> Hence, we are asking hardware engineer to find out the
> solution so that the driver does not need to do any dirty hacking. And
> so, this table should still be here even hardware fix will take place
> or not.

[...]

Best regards,
Marek Vasut

[Alexander Stein]

Hello Marek,

Do you mean specifying partitions in OF is deprecated in general? Is there any link for that?
What would be an alternative to it?

Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexand...@systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100

Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

[Brian Norris]

This is the first I've heard of such a deprecation. I would argue that
it's still probably one of the best ways to specify partitions. It's not
exactly perfect (partitions aren't really "hardware", so may not belong
in the "hardware description"), but IMO it's better than cmdlineparts,
for instance. I also don't really know of any good-enough, generically
useful on-flash partition formats, especially ones that can handle the
complexities of NAND.

Brian

[Brian Norris]

On Thu, Aug 20, 2015 at 05:18:14PM +0800, Viet Nga Dao wrote:
> You might misunderstand the hardware problem i mention here. This soft
> IP controller is able to provide the ID for our Altera EPCS/EPCQ flash
> chips, which are non JEDEC chips. As from EPCQ device data sheet
> (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf),
> the device ID is 8 bit data.

8 bits of data is vastly insufficient for uniquely identifying a flash.
This is not extendible and is not really a candidate for inclusion in
mainline, unless it's somehow guaranteed that these flash can only be
used with your controller (and I'm not sure how you would do that).
Otherwise, you need to augment every flash with more out-of-band
device-tree information.

> The remaining problem here is that this
> controller is able to support Micron chips but it currently has
> limitation in providing only 8 bit ID, which is not full JEDEC ID for
> Micron chips.

You're just proving my point. I will not support "READ ID" detection
that is based on only 8 bits of ID.

> Hence, we are asking hardware engineer to find out the
> solution so that the driver does not need to do any dirty hacking.

OK, then I wish your hardware team great speed.

> And
> so, this table should still be here even hardware fix will take place
> or not.

I'm not sure how you come to this conclusion.

BTW, to reiterate one other question that I feel wasn't adequately
answered: what does the full ID string look like for these EPCS/EPCQ
flash chips? Not the ID as seen by your limited controller, but the ID
that can be reported by the flash chip. Is it really only an 8-bit
number? Or does it have a longer string that your controller just can't
read?

Brian

[Brian Norris]

On Thu, Aug 20, 2015 at 11:42:18AM +0200, Marek Vasut wrote:
> On Thursday, August 20, 2015 at 11:18:14 AM, Viet Nga Dao wrote:
> > You might misunderstand the hardware problem i mention here. This soft
> > IP controller is able to provide the ID for our Altera EPCS/EPCQ flash
> > chips, which are non JEDEC chips. As from EPCQ device data sheet
> > (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature
> > /hb/cfg/cfg_cf52012.pdf), the device ID is 8 bit data.
>
> So what exactly is the output of READID instruction followed by 6 Byte read
> on an EPCQ chip?

+1 to this question

[Marek Vasut]

Which is the reasoning why I heard it was deprecated, but it seems my
knowledge is not correct. I apologize for the misinformation, sorry.

> , but IMO it's better than cmdlineparts,
> for instance. I also don't really know of any good-enough, generically
> useful on-flash partition formats, especially ones that can handle the
> complexities of NAND.

Right.

Best regards,
Marek Vasut

[Viet Nga Dao]

I have this conclusion is because Altera EPCQ/EPCS flashes are non
JEDEC. Thus on the spi_device_id table,
the ID in the INFO struct must be filled up with zeros in order to
matches the current framework.
However, since i still persist to have the device id check in my
driver, as suggested by Rash,
I should implement it locally in my driver. And this table is the look
up table for the device ID of supported flashes.

Or maybe you can give me any other better idea?

> BTW, to reiterate one other question that I feel wasn't adequately
> answered: what does the full ID string look like for these EPCS/EPCQ
> flash chips? Not the ID as seen by your limited controller, but the ID
> that can be reported by the flash chip. Is it really only an 8-bit
> number? Or does it have a longer string that your controller just can't
> read?
>

Yes, As you can refer to page 32 of EPCQ flash datasheet
(https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf),
"This operation reads the 8-bit device identification of the EPCQ
device from the DATA1 output pin".
Table 29 lists the EPCQ device identifications

Nga

[Viet Nga Dao]

Hi, i decided to wait for the hardware fixed and tested before
submitting new patch.
Thanks for all for your reviews and comments.
Viet Nga