Re: [SkyHigh Memory SPI NAND Driver]

Re: [SkyHigh Memory SPI NAND Driver]

[Miquel Raynal]

Hi Mohamed,

moh.sardi@skyhighmemory.com wrote on Thu, 4 Jan 2024 18:21:52 +0000:

> Hello SPI NOR / NAND Flash Subsytem team,
> 
> Please find attached the driver developed on Linux 5.4 and tested.. for our 1Gb/2Gb/4Gb SPI NAND…
> 
> We would like to know
> 
> 
>   1.  Who is in charge of supporting SPI NAND driver update and understand the process?

I'd like to say "the community", and that means anybody who wants to
interact on this topic. I will probably be the guy who eventually
applies the patch(es).

>   2.  How many version of this driver we need to develop to support all version of Linux (now being 6.xxx)?

We only bring support to the latest mainline kernel, whatever version
it could be. So if you send a patch (please follow the contributing
guidelines in Documentation/) it should be a diff against the next -rc1
(so it will be v6.8-rc1 in two weeks). You can share diffs for other
versions as well on your own website but there is usually no backport
of 'new features'.

> For instance if the driver (attached is 5.4), can it be used up to 5.18…  or should we modify it starting from version 5.4x.

If it compiles, it will probably work as well as the core has not
changed much since it's been created, but there is of course no
guarantee.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Mohamed Sardi]

Hello Miquel,
Thank you for your response. Mr KR cc'ed (Our application Engineer Director) will be the main contact in our side...

Thanks
Mohamed 

On 1/8/24, 5:47 AM, "Miquel Raynal" <miquel.raynal@bootlin.com <mailto:miquel.raynal@bootlin.com>> wrote:


Hi Mohamed,


moh.sardi@skyhighmemory.com <mailto:moh.sardi@skyhighmemory.com> wrote on Thu, 4 Jan 2024 18:21:52 +0000:


> Hello SPI NOR / NAND Flash Subsytem team,
> 
> Please find attached the driver developed on Linux 5.4 and tested.. for our 1Gb/2Gb/4Gb SPI NAND…
> 
> We would like to know
> 
> 
> 1. Who is in charge of supporting SPI NAND driver update and understand the process?


I'd like to say "the community", and that means anybody who wants to
interact on this topic. I will probably be the guy who eventually
applies the patch(es).


> 2. How many version of this driver we need to develop to support all version of Linux (now being 6.xxx)?


We only bring support to the latest mainline kernel, whatever version
it could be. So if you send a patch (please follow the contributing
guidelines in Documentation/) it should be a diff against the next -rc1
(so it will be v6.8-rc1 in two weeks). You can share diffs for other
versions as well on your own website but there is usually no backport
of 'new features'.


> For instance if the driver (attached is 5.4), can it be used up to 5.18… or should we modify it starting from version 5.4x.


If it compiles, it will probably work as well as the core has not
changed much since it's been created, but there is of course no
guarantee.


Thanks,
Miquèl



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Miquel Raynal]

Hi Kim,

> >   2.  How many version of this driver we need to develop to support all version of Linux (now being 6.xxx)?  
> 
> We only bring support to the latest mainline kernel, whatever version it could be. So if you send a patch (please follow the contributing guidelines in Documentation/) it should be a diff against the next -rc1 (so it will be v6.8-rc1 in two weeks). You can share diffs for other versions as well on your own website but there is usually no backport of 'new features'.
> 
> [KR] Simply, you can only support for our patch to the latest version. Is that right?

Well, there is only one "mainline", and your contributions must match
the state of this mainline. When applying the patch, the next kernel
and all others following will have support for your chips.
> 
> > For instance if the driver (attached is 5.4), can it be used up to 5.18…  or should we modify it starting from version 5.4x.  
> 
> If it compiles, it will probably work as well as the core has not changed much since it's been created, but there is of course no guarantee.
> 
> [KR] Is it possible to apply the patch to old version of Linux community?

On your side you can provide a diff for each kernel version that you
want to support which does not contain your patch series. For all
kernel versions after your changes have been merged, there is nothing
additional to do on your side (besides posting updates/fixes maybe).
You cannot backport a feature to older (stable) kernels.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Mohamed Sardi]

Hello Miquel,

I have a question for bad block marking and checking on Linux... and ECC.

Do you know how bad block marking is done?

1) Bad Block Marking: Are your writing non FF on the first 2 bytes of the OOB? Do you keep Device ECC ON or OFF?
2) Bad block Checking: Do you read the first 2 bytes of the OOB with ECC OFF or do you keep ECC ON?

Thanks,
Mohamed 

On 1/11/24, 3:38 AM, "Miquel Raynal" <miquel.raynal@bootlin.com <mailto:miquel.raynal@bootlin.com>> wrote:


Hi Kim,


> > 2. How many version of this driver we need to develop to support all version of Linux (now being 6.xxx)? 
> 
> We only bring support to the latest mainline kernel, whatever version it could be. So if you send a patch (please follow the contributing guidelines in Documentation/) it should be a diff against the next -rc1 (so it will be v6.8-rc1 in two weeks). You can share diffs for other versions as well on your own website but there is usually no backport of 'new features'.
> 
> [KR] Simply, you can only support for our patch to the latest version. Is that right?


Well, there is only one "mainline", and your contributions must match
the state of this mainline. When applying the patch, the next kernel
and all others following will have support for your chips.
> 
> > For instance if the driver (attached is 5.4), can it be used up to 5.18… or should we modify it starting from version 5.4x. 
> 
> If it compiles, it will probably work as well as the core has not changed much since it's been created, but there is of course no guarantee.
> 
> [KR] Is it possible to apply the patch to old version of Linux community?


On your side you can provide a diff for each kernel version that you
want to support which does not contain your patch series. For all
kernel versions after your changes have been merged, there is nothing
additional to do on your side (besides posting updates/fixes maybe).
You cannot backport a feature to older (stable) kernels.


Thanks,
Miquèl



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Miquel Raynal]

Hi Mohamed,

moh.sardi@skyhighmemory.com wrote on Tue, 23 Jan 2024 01:01:53 +0000:

> Hello Miquel,
> 
> I have a question for bad block marking and checking on Linux... and ECC.
> 
> Do you know how bad block marking is done?
> 
> 1) Bad Block Marking: Are your writing non FF on the first 2 bytes of the OOB? Do you keep Device ECC ON or OFF?
> 2) Bad block Checking: Do you read the first 2 bytes of the OOB with ECC OFF or do you keep ECC ON?

In the raw NAND world, for legacy reasons these checks and writes are
done with the correction engine enabled. But I believe you are
interested into the SPI-NAND side only, and in this case the ECC is
always disabled:

Marking:
https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L768
Checking:
https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L733

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Mohamed Sardi]

Hello Miquel,
Thank you for your response. 

Our understanding is aligned with your comment.


Thanks
Mohamed 

On 1/24/24, 1:07 PM, "Miquel Raynal" <miquel.raynal@bootlin.com <mailto:miquel.raynal@bootlin.com>> wrote:


Hi Mohamed,


moh.sardi@skyhighmemory.com <mailto:moh.sardi@skyhighmemory.com> wrote on Tue, 23 Jan 2024 01:01:53 +0000:


> Hello Miquel,
> 
> I have a question for bad block marking and checking on Linux... and ECC.
> 
> Do you know how bad block marking is done?
> 
> 1) Bad Block Marking: Are your writing non FF on the first 2 bytes of the OOB? Do you keep Device ECC ON or OFF?
> 2) Bad block Checking: Do you read the first 2 bytes of the OOB with ECC OFF or do you keep ECC ON?


In the raw NAND world, for legacy reasons these checks and writes are
done with the correction engine enabled. But I believe you are
interested into the SPI-NAND side only, and in this case the ECC is
always disabled:


Marking:
https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L768 <https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L768>
Checking:
https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L733 <https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L733>


Thanks,
Miquèl



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Mohamed Sardi]

Dear Miquel,
We understand that your plan to turn off the ECC for Bad Block marking and checking... for Linux V6...

We also understand that in Linux5.4 the driver did not have ECC control...

My question is as follow:
1) From which version of Linux ,the ECC control was added in the driver? Was it implemented in Linux 5.xx?
2) What was the leading reason/customer leading to turn off the ECC for bad block marking/checking?
Note: We saw that MTK was turning off the ECC for Bad block marking on Linux 5.4...

3) We think that the ECC should be turned off for bad block marking and checking, is it possible for us to provide a patch/driver (SHM_core.c) for Linux version version 6...  where SHM devices keep the ECC on...
 

Thanks
Mohamed 

On 1/24/24, 1:07 PM, "Miquel Raynal" <miquel.raynal@bootlin.com <mailto:miquel.raynal@bootlin.com>> wrote:


Hi Mohamed,


moh.sardi@skyhighmemory.com <mailto:moh.sardi@skyhighmemory.com> wrote on Tue, 23 Jan 2024 01:01:53 +0000:


> Hello Miquel,
> 
> I have a question for bad block marking and checking on Linux... and ECC.
> 
> Do you know how bad block marking is done?
> 
> 1) Bad Block Marking: Are your writing non FF on the first 2 bytes of the OOB? Do you keep Device ECC ON or OFF?
> 2) Bad block Checking: Do you read the first 2 bytes of the OOB with ECC OFF or do you keep ECC ON?


In the raw NAND world, for legacy reasons these checks and writes are
done with the correction engine enabled. But I believe you are
interested into the SPI-NAND side only, and in this case the ECC is
always disabled:


Marking:
https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L768 <https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L768>
Checking:
https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L733 <https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/mtd/nand/spi/core.c#L733>


Thanks,
Miquèl



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Miquel Raynal]

Hi Mohamed,

moh.sardi@skyhighmemory.com wrote on Thu, 1 Feb 2024 19:40:51 +0000:

> Dear Miquel,
> We understand that your plan to turn off the ECC for Bad Block marking and checking... for Linux V6...

No, it's always been like this, I don't think we ever changed that.
Turning ECC on in the raw NAND world was maybe a mistake and was proven
not useful to SPI-NANDs so, it was disabled in the SPI-NAND world from
day 1, AFAIR.

> We also understand that in Linux5.4 the driver did not have ECC control...

Not sure what "driver" means here.

> My question is as follow:
> 1) From which version of Linux ,the ECC control was added in the driver? Was it implemented in Linux 5.xx?

Again, what is "driver"? ECC correction is mandatory for page accesses,
it's always been there.

> 2) What was the leading reason/customer leading to turn off the ECC for bad block marking/checking?
> Note: We saw that MTK was turning off the ECC for Bad block marking on Linux 5.4...

It's not been turned off or on, as I told you in my previous mail.

> 3) We think that the ECC should be turned off for bad block marking and checking, is it possible for us to provide a patch/driver (SHM_core.c) for Linux version version 6...  where SHM devices keep the ECC on...

It is already off in the SPI-NAND world. Sorry if I am not
understanding what you say correctly, but I'll need more precise
information to answer correctly.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Mohamed Sardi]

Hello Miquel
Maybe my question is not clear. Is ti possible to setup a time to discuss further next week. 

I am located in Pacific Time. I can setup a conference call... Can you let me know what day and time work for you so I can send the ZOOM call?


Thanks
Mohamed 
On 2/2/24, 12:11 PM, "Miquel Raynal" <miquel.raynal@bootlin.com <mailto:miquel.raynal@bootlin.com>> wrote:


Hi Mohamed,


moh.sardi@skyhighmemory.com <mailto:moh.sardi@skyhighmemory.com> wrote on Thu, 1 Feb 2024 19:40:51 +0000:


> Dear Miquel,
> We understand that your plan to turn off the ECC for Bad Block marking and checking... for Linux V6...


No, it's always been like this, I don't think we ever changed that.
Turning ECC on in the raw NAND world was maybe a mistake and was proven
not useful to SPI-NANDs so, it was disabled in the SPI-NAND world from
day 1, AFAIR.


> We also understand that in Linux5.4 the driver did not have ECC control...


Not sure what "driver" means here.


> My question is as follow:
> 1) From which version of Linux ,the ECC control was added in the driver? Was it implemented in Linux 5.xx?


Again, what is "driver"? ECC correction is mandatory for page accesses,
it's always been there.


> 2) What was the leading reason/customer leading to turn off the ECC for bad block marking/checking?
> Note: We saw that MTK was turning off the ECC for Bad block marking on Linux 5.4...


It's not been turned off or on, as I told you in my previous mail.


> 3) We think that the ECC should be turned off for bad block marking and checking, is it possible for us to provide a patch/driver (SHM_core.c) for Linux version version 6... where SHM devices keep the ECC on...


It is already off in the SPI-NAND world. Sorry if I am not
understanding what you say correctly, but I'll need more precise
information to answer correctly.


Thanks,
Miquèl



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [SkyHigh Memory SPI NAND Driver]

[Miquel Raynal]

Hi Mohamed,

moh.sardi@skyhighmemory.com wrote on Fri, 2 Feb 2024 16:17:43 +0000:

> Hello Miquel
> Maybe my question is not clear. Is ti possible to setup a time to discuss further next week. 
> 
> I am located in Pacific Time. I can setup a conference call... Can you let me know what day and time work for you so I can send the ZOOM call?

I would prefer if you could be more precise by e-mail. You are talking
to the community here, not just me.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [SkyHigh Memory SPI NAND Driver]

[Kyeongrho.Kim]

[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]

Hello Miquel,

Please find the attached that is Skyhighmemory's patch file for SPI nand.
I tried to send a patch file through 'git send-email', but it didn't work.
So I first send a patch file of Skyhighmemory through Outlook.
If necessary, I'm going to try through 'git send-email', do I need it?
Please let me know if you have any questions.
Thanks,
KR

-----Original Message-----
From: Miquel Raynal <miquel.raynal@bootlin.com> 
Sent: Thursday, January 11, 2024 4:39 PM
To: Kyeongrho.Kim <kr.kim@skyhighmemory.com>
Cc: Mohamed Sardi <moh.sardi@skyhighmemory.com>; tudor.ambarus@microchip.com; p.yadav@ti.com; linux-mtd@lists.infradead.org; richard@nod.at; Mohammad Nada <Mohammad.nada@skyhighmemory.com>; Changsub.Shim <changsub.shim@skyhighmemory.com>
Subject: Re: [SkyHigh Memory SPI NAND Driver]

Hi Kim,

> >   2.  How many version of this driver we need to develop to support all version of Linux (now being 6.xxx)?  
> 
> We only bring support to the latest mainline kernel, whatever version it could be. So if you send a patch (please follow the contributing guidelines in Documentation/) it should be a diff against the next -rc1 (so it will be v6.8-rc1 in two weeks). You can share diffs for other versions as well on your own website but there is usually no backport of 'new features'.
> 
> [KR] Simply, you can only support for our patch to the latest version. Is that right?

Well, there is only one "mainline", and your contributions must match the state of this mainline. When applying the patch, the next kernel and all others following will have support for your chips.
> 
> > For instance if the driver (attached is 5.4), can it be used up to 5.18…  or should we modify it starting from version 5.4x.  
> 
> If it compiles, it will probably work as well as the core has not changed much since it's been created, but there is of course no guarantee.
> 
> [KR] Is it possible to apply the patch to old version of Linux community?

On your side you can provide a diff for each kernel version that you want to support which does not contain your patch series. For all kernel versions after your changes have been merged, there is nothing additional to do on your side (besides posting updates/fixes maybe).
You cannot backport a feature to older (stable) kernels.

Thanks,
Miquèl

[-- Attachment #2: 0001-Skyhighmemory.patch --]
[-- Type: application/octet-stream, Size: 9575 bytes --]

From 4aedf803907f905b867e6a28ee7a2317ce10d29b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E2=80=9CKyeongrho?= <kr.kim@skyhighmemory.com>
Date: Tue, 20 Feb 2024 19:19:57 +0900
Subject: [PATCH] Skyhighmemory
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: “Kyeongrho <kr.kim@skyhighmemory.com>
---
 drivers/mtd/nand/spi/Makefile  |   2 +-
 drivers/mtd/nand/spi/core.c    |   7 +-
 drivers/mtd/nand/spi/skyhigh.c | 191 +++++++++++++++++++++++++++++++++
 include/linux/mtd/spinand.h    |   3 +
 4 files changed, 201 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 drivers/mtd/nand/spi/Makefile
 mode change 100644 => 100755 drivers/mtd/nand/spi/core.c
 create mode 100644 drivers/mtd/nand/spi/skyhigh.c
 mode change 100644 => 100755 include/linux/mtd/spinand.h

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
old mode 100644
new mode 100755
index 19cc77288ebb..48b429d90460
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 spinand-objs := core.o alliancememory.o ato.o esmt.o foresee.o gigadevice.o macronix.o
-spinand-objs += micron.o paragon.o toshiba.o winbond.o xtx.o
+spinand-objs += micron.o paragon.o toshiba.o winbond.o xtx.o skyhigh.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
old mode 100644
new mode 100755
index e0b6715e5dfe..e3f0a7544ba4
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -34,7 +34,7 @@ static int spinand_read_reg_op(struct spinand_device *spinand, u8 reg, u8 *val)
 	return 0;
 }
 
-static int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
+int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val)
 {
 	struct spi_mem_op op = SPINAND_SET_FEATURE_OP(reg,
 						      spinand->scratchbuf);
@@ -196,6 +196,10 @@ static int spinand_init_quad_enable(struct spinand_device *spinand)
 static int spinand_ecc_enable(struct spinand_device *spinand,
 			      bool enable)
 {
+	/* SHM : always ECC enable */
+	if (spinand->flags & SPINAND_ON_DIE_ECC_MANDATORY)
+		return 0;
+
 	return spinand_upd_cfg(spinand, CFG_ECC_ENABLE,
 			       enable ? CFG_ECC_ENABLE : 0);
 }
@@ -945,6 +949,7 @@ static const struct spinand_manufacturer *spinand_manufacturers[] = {
 	&macronix_spinand_manufacturer,
 	&micron_spinand_manufacturer,
 	&paragon_spinand_manufacturer,
+	&skyhigh_spinand_manufacturer,
 	&toshiba_spinand_manufacturer,
 	&winbond_spinand_manufacturer,
 	&xtx_spinand_manufacturer,
diff --git a/drivers/mtd/nand/spi/skyhigh.c b/drivers/mtd/nand/spi/skyhigh.c
new file mode 100644
index 000000000000..71de4fa34406
--- /dev/null
+++ b/drivers/mtd/nand/spi/skyhigh.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 SkyHigh Memory Limited
+ *
+ * Author: Takahiro Kuwano <takahiro.kuwano@infineon.com>
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mtd/spinand.h>
+
+#define SPINAND_MFR_SKYHIGH		0x01
+
+#define SKYHIGH_STATUS_ECC_1TO2_BITFLIPS	(1 << 4)
+#define SKYHIGH_STATUS_ECC_3TO4_BITFLIPS	(2 << 4)
+#define SKYHIGH_STATUS_ECC_5TO6_BITFLIPS	(3 << 4)
+
+#define SKYHIGH_CONFIG_PROTECT_EN	BIT(1)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+		SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 4, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 2, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+		SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+		SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+		SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+		SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int skyhigh_spinand_ooblayout_ecc(struct mtd_info *mtd, int section,
+					 struct mtd_oob_region *region)
+{
+	if (section)
+		return -ERANGE;
+
+	region->length = 0;
+	region->offset = mtd->oobsize;
+
+	return 0;
+}
+
+static int skyhigh_spinand_ooblayout_free(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *region)
+{
+	if (section)
+		return -ERANGE;
+
+	region->length = mtd->oobsize - 2;
+	region->offset = 2;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops skyhigh_spinand_ooblayout = {
+	.ecc = skyhigh_spinand_ooblayout_ecc,
+	.free = skyhigh_spinand_ooblayout_free,
+};
+
+#if 0
+bool skyhigh_spinand_isbad(struct spinand_device *spinand,
+			   const struct nand_pos *pos)
+{
+	u8 marker;
+	struct nand_page_io_req req = {
+		.pos = *pos,
+		.ooblen = 1,
+		.ooboffs = 0,
+		.oobbuf.in = &marker,
+		.mode = MTD_OPS_RAW,
+	};
+
+	req.pos.page = 0;
+	spinand_read_page(spinand, &req);
+	if (marker != 0xff)
+		return true;
+
+#if 0
+	req.pos.page = 1;
+	spinand_read_page(spinand, &req);
+	if (marker != 0xff)
+		return true;
+
+	req.pos.page = 63;
+	spinand_read_page(spinand, &req);
+	if (marker != 0xff)
+		return true;
+#endif
+
+	return false;
+}
+#endif
+
+static int skyhigh_spinand_ecc_get_status(struct spinand_device *spinand,
+				  u8 status)
+{
+	/* SHM
+	00 : No bit-flip
+	01 : 1-2 errors corrected
+	10 : 3-6 errors corrected         
+	11 : uncorrectable
+	*/
+
+	switch (status & STATUS_ECC_MASK) {
+	case STATUS_ECC_NO_BITFLIPS:
+		return 0;
+
+	case SKYHIGH_STATUS_ECC_1TO2_BITFLIPS:
+		return 2;
+
+	/* change from 4 to 6 */
+	case SKYHIGH_STATUS_ECC_3TO4_BITFLIPS:
+		return 6; 
+
+	/* uncorrectable for '11' */
+	case SKYHIGH_STATUS_ECC_5TO6_BITFLIPS:
+		return -EBADMSG;;
+
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static const struct spinand_info skyhigh_spinand_table[] = {
+	SPINAND_INFO("S35ML01G301",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x15),
+		     NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+	SPINAND_INFO("S35ML01G300",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x14),
+		     NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+	SPINAND_INFO("S35ML02G300",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x25),
+		     NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 2, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+	SPINAND_INFO("S35ML04G300",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x35),
+		     NAND_MEMORG(1, 2048, 128, 64, 4096, 80, 2, 1, 1),
+		     NAND_ECCREQ(6, 32),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_ON_DIE_ECC_MANDATORY,
+		     SPINAND_ECCINFO(&skyhigh_spinand_ooblayout,
+		     		     skyhigh_spinand_ecc_get_status)),
+};
+
+static int skyhigh_spinand_init(struct spinand_device *spinand)
+{
+	return spinand_write_reg_op(spinand, REG_BLOCK_LOCK,
+				    SKYHIGH_CONFIG_PROTECT_EN);
+}
+
+static const struct spinand_manufacturer_ops skyhigh_spinand_manuf_ops = {
+	.init = skyhigh_spinand_init,
+/*	.isbad = skyhigh_spinand_isbad,*/
+};
+
+const struct spinand_manufacturer skyhigh_spinand_manufacturer = {
+	.id = SPINAND_MFR_SKYHIGH,
+	.name = "SkyHigh",
+	.chips = skyhigh_spinand_table,
+	.nchips = ARRAY_SIZE(skyhigh_spinand_table),
+	.ops = &skyhigh_spinand_manuf_ops,
+};
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
old mode 100644
new mode 100755
index badb4c1ac079..0e135076df24
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -268,6 +268,7 @@ extern const struct spinand_manufacturer gigadevice_spinand_manufacturer;
 extern const struct spinand_manufacturer macronix_spinand_manufacturer;
 extern const struct spinand_manufacturer micron_spinand_manufacturer;
 extern const struct spinand_manufacturer paragon_spinand_manufacturer;
+extern const struct spinand_manufacturer skyhigh_spinand_manufacturer;
 extern const struct spinand_manufacturer toshiba_spinand_manufacturer;
 extern const struct spinand_manufacturer winbond_spinand_manufacturer;
 extern const struct spinand_manufacturer xtx_spinand_manufacturer;
@@ -312,6 +313,7 @@ struct spinand_ecc_info {
 
 #define SPINAND_HAS_QE_BIT		BIT(0)
 #define SPINAND_HAS_CR_FEAT_BIT		BIT(1)
+#define SPINAND_ON_DIE_ECC_MANDATORY	BIT(2)	/* SHM */
 
 /**
  * struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine structure
@@ -518,5 +520,6 @@ int spinand_match_and_init(struct spinand_device *spinand,
 
 int spinand_upd_cfg(struct spinand_device *spinand, u8 mask, u8 val);
 int spinand_select_target(struct spinand_device *spinand, unsigned int target);
+int spinand_write_reg_op(struct spinand_device *spinand, u8 reg, u8 val);
 
 #endif /* __LINUX_MTD_SPINAND_H */
-- 
2.34.1


[-- Attachment #3: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/