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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox