From: Boris Brezillon <bbrezillon@kernel.org>
To: Stefan Roese <sr@denx.de>
Cc: Chuanhong Guo <gch981213@gmail.com>,
linux-mtd@lists.infradead.org,
Frieder Schrempf <frieder.schrempf@kontron.de>,
Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: [PATCH] mtd: spinand: Add support for GigaDevice GD5F1GQ4UC
Date: Tue, 22 Jan 2019 17:54:20 +0100 [thread overview]
Message-ID: <20190122175346.602894e4@bbrezillon> (raw)
In-Reply-To: <20190122145632.17547-1-sr@denx.de>
On Tue, 22 Jan 2019 15:56:32 +0100
Stefan Roese <sr@denx.de> wrote:
> Add support for GigaDevice GD5F1GQ4UC SPI NAND chip.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Chuanhong Guo <gch981213@gmail.com>
> Cc: Frieder Schrempf <frieder.schrempf@kontron.de>
> Cc: Miquel Raynal <miquel.raynal@bootlin.com>
You forgot to Cc me on this one ;-).
> ---
> Frankly, I'm a bit unsure, if these new ooblayout_foo functions are
> needed for this device. I was unable to find a datasheet for the
> already supported devices (GD5F1G/2G/4GQ4xA), so I couldn't compare
> the OOB area values here with the ones for my SPI NAND chip.
Looks like it's using a different layout.
>
> I'm also not 100% sure, if I should use NAND_ECCREQ(8, 2048) or
> NAND_ECCREQ(8, 512) for this device.
Given the size reserved to store ECC bytes I'd say 8bits/512bytes.
There's an easy way to validate that => nandbiterrs (in mtd-utils).
>
> So comments welcome.
>
> Thanks,
> Stefan
>
> drivers/mtd/nand/spi/gigadevice.c | 39 +++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/mtd/nand/spi/gigadevice.c b/drivers/mtd/nand/spi/gigadevice.c
> index e4141c20947a..a9d256fa2577 100644
> --- a/drivers/mtd/nand/spi/gigadevice.c
> +++ b/drivers/mtd/nand/spi/gigadevice.c
> @@ -57,6 +57,31 @@ static int gd5fxgq4xa_ooblayout_free(struct mtd_info *mtd, int section,
> return 0;
> }
>
> +static int gd5f1gq4u_ooblayout_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *region)
> +{
> + if (section)
> + return -ERANGE;
> +
> + region->offset = 64;
> + region->length = 64;
> +
> + return 0;
> +}
> +
> +static int gd5f1gq4u_ooblayout_free(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *region)
> +{
> + if (section)
> + return -ERANGE;
> +
> + /* Reserve 2 bytes for the BBM. */
> + region->offset = 2;
According to the datasheet, the BBM is only one byte large.
> + region->length = 62;
> +
> + return 0;
> +}
> +
> static int gd5fxgq4xa_ecc_get_status(struct spinand_device *spinand,
> u8 status)
> {
> @@ -86,6 +111,11 @@ static const struct mtd_ooblayout_ops gd5fxgq4xa_ooblayout = {
> .free = gd5fxgq4xa_ooblayout_free,
> };
>
> +static const struct mtd_ooblayout_ops gd5f1gq4u_ooblayout = {
> + .ecc = gd5f1gq4u_ooblayout_ecc,
> + .free = gd5f1gq4u_ooblayout_free,
> +};
> +
> static const struct spinand_info gigadevice_spinand_table[] = {
> SPINAND_INFO("GD5F1GQ4xA", 0xF1,
> NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 1),
> @@ -114,6 +144,15 @@ static const struct spinand_info gigadevice_spinand_table[] = {
> 0,
> SPINAND_ECCINFO(&gd5fxgq4xa_ooblayout,
> gd5fxgq4xa_ecc_get_status)),
> + SPINAND_INFO("GD5F1GQ4UC", 0xd1,
> + NAND_MEMORG(1, 2048, 128, 64, 1024, 1, 1, 1),
> + NAND_ECCREQ(8, 2048),
> + SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
> + &write_cache_variants,
> + &update_cache_variants),
> + 0,
> + SPINAND_ECCINFO(&gd5f1gq4u_ooblayout,
> + gd5fxgq4xa_ecc_get_status)),
The gd5fxgq4xa_ecc_get_status() func does not work for this chip.
Something like that should do the trick:
#define GD5F1GQ4U_ECC_STATUS_MASK GENMASK(6, 4)
static int gd5f1gq4u_ecc_get_status(struct spinand_device *spinand,
u8 status)
{
unsigned int nbitflips;
nbitflips = (status & GD5F1GQ4U_ECC_STATUS_MASK) >> 4;
if (!nbitflips)
return 0;
nbitflips += 2;
if (nbitflips > 8)
return -EBADMSG;
return nbitflips
}
> };
>
> static int gigadevice_spinand_detect(struct spinand_device *spinand)
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-01-22 16:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 14:56 [PATCH] mtd: spinand: Add support for GigaDevice GD5F1GQ4UC Stefan Roese
2019-01-22 16:54 ` Boris Brezillon [this message]
2019-01-23 6:57 ` Stefan Roese
2019-01-23 7:52 ` Boris Brezillon
2019-01-23 8:23 ` Stefan Roese
2019-01-23 8:55 ` Boris Brezillon
2019-01-23 9:06 ` Stefan Roese
2019-01-23 9:35 ` Boris Brezillon
2019-01-23 10:04 ` Stefan Roese
2019-01-23 11:25 ` Boris Brezillon
2019-01-23 11:28 ` Boris Brezillon
2019-01-23 11:37 ` Stefan Roese
2019-01-23 12:18 ` Stefan Roese
2019-01-23 12:22 ` Boris Brezillon
2019-01-23 12:34 ` Stefan Roese
2019-01-23 12:40 ` Boris Brezillon
2019-01-23 12:57 ` Boris Brezillon
2019-01-23 13:20 ` Stefan Roese
2019-01-24 7:35 ` Stefan Roese
2019-01-24 7:50 ` Boris Brezillon
2019-01-24 8:00 ` Stefan Roese
2019-01-24 8:14 ` Boris Brezillon
2019-01-24 8:52 ` Stefan Roese
2019-01-24 9:04 ` Boris Brezillon
2019-01-24 9:19 ` Boris Brezillon
2019-01-24 10:57 ` Stefan Roese
2019-01-24 11:14 ` Boris Brezillon
2019-01-24 11:59 ` Stefan Roese
2019-01-24 12:18 ` Boris Brezillon
2019-01-24 12:28 ` Stefan Roese
2019-01-24 12:41 ` Boris Brezillon
2019-01-24 13:59 ` Stefan Roese
2019-01-24 16:36 ` Boris Brezillon
2019-01-24 8:34 ` Boris Brezillon
2019-01-24 7:52 ` Boris Brezillon
2019-01-24 8:00 ` Stefan Roese
2019-01-22 16:58 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190122175346.602894e4@bbrezillon \
--to=bbrezillon@kernel.org \
--cc=frieder.schrempf@kontron.de \
--cc=gch981213@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=sr@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.