From: Marek Vasut <marex@denx.de>
To: Huang Shijie <shijie8@gmail.com>
Cc: fabio.estevam@freescale.com, dedekind1@gmail.com,
Huang Shijie <b32955@freescale.com>,
linux-mtd@lists.infradead.org, shawn.guo@linaro.org,
dwmw2@infradead.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] mtd: gpmi: add NAND write verify support
Date: Fri, 10 Aug 2012 17:04:44 +0200 [thread overview]
Message-ID: <201208101704.44984.marex@denx.de> (raw)
In-Reply-To: <CAMiH66FAVVPLZ9hCyRcNCm1Le2JrCc+55CUw7UCtPjw+31w5gw@mail.gmail.com>
Dear Huang Shijie,
> On Fri, Aug 10, 2012 at 7:25 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Huang Shijie,
> >
> >> Add NAND write verify support in gpmi-nand driver.
> >>
> >> Signed-off-by: Huang Shijie <b32955@freescale.com>
> >> ---
> >>
> >> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 17 +++++++++++++++++
> >> 1 files changed, 17 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> >> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index 8c0d2f0..6394483 100644
> >> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> >> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> >> @@ -1488,6 +1488,22 @@ static int gpmi_set_geometry(struct
> >> gpmi_nand_data *this) return gpmi_alloc_dma_buffer(this);
> >>
> >> }
> >>
> >> +#define MAX_PAGESIZE 8192
> >
> > Use NAND_MAX_PAGESIZE, see include/linux/mtd/nand.h .
> >
> >> +static uint8_t verify_buf[MAX_PAGESIZE];
>
> ok, thanks.
>
> > What will happen when you have two NANDs attached to GPMI controller and
> > they hit this place both at once? Race condition, causing this function
> > to fail for both?
>
> Even there are two nand chips, there is only one gpmi controller.
For now ... yes.
> And the current gpmi-nand does not support two nands now.
> does the race occur with only one nand chip?
With one chip and one GPMI controller, no ... but that's no reason to introduce
crappy and error prone code!
> > Possibly devm_kmalloc() such buffer per-controller?
> >
> >> +static int gpmi_verify_buf(struct mtd_info *mtd, const uint8_t *buf,
> >> int len) +{
> >> + struct nand_chip *nand = mtd->priv;
> >> + int ret;
> >> +
> >> + ret = gpmi_ecc_read_page(mtd, nand, verify_buf, 0, 0);
> >
> > mtd->chip.ecc.read_page() ?
>
> In actually, they are the same.
They are, but if you rename the function, this is one less place to care for.
>
> Best Regards
> Huang Shijie
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mtd: gpmi: add NAND write verify support
Date: Fri, 10 Aug 2012 17:04:44 +0200 [thread overview]
Message-ID: <201208101704.44984.marex@denx.de> (raw)
In-Reply-To: <CAMiH66FAVVPLZ9hCyRcNCm1Le2JrCc+55CUw7UCtPjw+31w5gw@mail.gmail.com>
Dear Huang Shijie,
> On Fri, Aug 10, 2012 at 7:25 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Huang Shijie,
> >
> >> Add NAND write verify support in gpmi-nand driver.
> >>
> >> Signed-off-by: Huang Shijie <b32955@freescale.com>
> >> ---
> >>
> >> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 17 +++++++++++++++++
> >> 1 files changed, 17 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> >> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index 8c0d2f0..6394483 100644
> >> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> >> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> >> @@ -1488,6 +1488,22 @@ static int gpmi_set_geometry(struct
> >> gpmi_nand_data *this) return gpmi_alloc_dma_buffer(this);
> >>
> >> }
> >>
> >> +#define MAX_PAGESIZE 8192
> >
> > Use NAND_MAX_PAGESIZE, see include/linux/mtd/nand.h .
> >
> >> +static uint8_t verify_buf[MAX_PAGESIZE];
>
> ok, thanks.
>
> > What will happen when you have two NANDs attached to GPMI controller and
> > they hit this place both at once? Race condition, causing this function
> > to fail for both?
>
> Even there are two nand chips, there is only one gpmi controller.
For now ... yes.
> And the current gpmi-nand does not support two nands now.
> does the race occur with only one nand chip?
With one chip and one GPMI controller, no ... but that's no reason to introduce
crappy and error prone code!
> > Possibly devm_kmalloc() such buffer per-controller?
> >
> >> +static int gpmi_verify_buf(struct mtd_info *mtd, const uint8_t *buf,
> >> int len) +{
> >> + struct nand_chip *nand = mtd->priv;
> >> + int ret;
> >> +
> >> + ret = gpmi_ecc_read_page(mtd, nand, verify_buf, 0, 0);
> >
> > mtd->chip.ecc.read_page() ?
>
> In actually, they are the same.
They are, but if you rename the function, this is one less place to care for.
>
> Best Regards
> Huang Shijie
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-08-10 15:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-10 3:18 [PATCH] mtd: gpmi: add NAND write verify support Huang Shijie
2012-08-10 3:18 ` Huang Shijie
2012-08-10 4:12 ` Fabio Estevam
2012-08-10 4:12 ` Fabio Estevam
2012-08-10 11:25 ` Marek Vasut
2012-08-10 11:25 ` Marek Vasut
2012-08-10 14:15 ` Huang Shijie
2012-08-10 14:15 ` Huang Shijie
2012-08-10 15:04 ` Marek Vasut [this message]
2012-08-10 15:04 ` Marek Vasut
2012-08-10 17:15 ` Fabio Estevam
2012-08-10 17:15 ` Fabio Estevam
2012-08-10 19:33 ` Marek Vasut
2012-08-10 19:33 ` Marek Vasut
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=201208101704.44984.marex@denx.de \
--to=marex@denx.de \
--cc=b32955@freescale.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=fabio.estevam@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=shawn.guo@linaro.org \
--cc=shijie8@gmail.com \
/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.