| Message ID | 1315800250-19761-4-git-send-email-marek.vasut@gmail.com |
|---|---|
| State | Deferred |
| Delegated to: | Scott Wood |
| Headers | show |
On 09/11/2011 11:04 PM, Marek Vasut wrote: > Don't allocate NAND buffers as one block, but allocate them separately. This > allows systems where DMA to buffers happen to allocate these buffers properly > aligned. > > Signed-off-by: Marek Vasut <marek.vasut@gmail.com> > Cc: Scott Wood <scottwood@freescale.com> > Cc: Stefano Babic <sbabic@denx.de> > Cc: Wolfgang Denk <wd@denx.de> > Cc: Detlev Zundel <dzu@denx.de> > --- > drivers/mtd/nand/nand_base.c | 30 +++++++++++++++++++++++------- > include/linux/mtd/nand.h | 7 ++++--- > 2 files changed, 27 insertions(+), 10 deletions(-) Is this hardware going to be supported in Linux? It would be nice if we could keep this code in sync. -Scott
Dear Scott Wood, In message <4E7A320D.1030002@freescale.com> you wrote: > > Is this hardware going to be supported in Linux? It would be nice if we > could keep this code in sync. Stefano has submitted patches for the iMX28 based M28 / M28EVK board, so yes, this hardware going to be supported in mainline Linux, too. Best regards, Wolfgang Denk
On 09/21/2011 02:49 PM, Wolfgang Denk wrote: > Dear Scott Wood, > > In message <4E7A320D.1030002@freescale.com> you wrote: >> >> Is this hardware going to be supported in Linux? It would be nice if we >> could keep this code in sync. > > Stefano has submitted patches for the iMX28 based M28 / M28EVK board, > so yes, this hardware going to be supported in mainline Linux, too. > > Best regards, > > Wolfgang Denk > How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? I'd like to see this change be submitted to Linux first, or else have an explanation of why a divergence for U-Boot is warranted. -Scott
Dear Stefano & Marek, can you please provide the requested information? In message <4E7A4145.30501@freescale.com> Scott Wood wrote: > > > In message <4E7A320D.1030002@freescale.com> you wrote: > >> > >> Is this hardware going to be supported in Linux? It would be nice if we > >> could keep this code in sync. > > > > Stefano has submitted patches for the iMX28 based M28 / M28EVK board, > > so yes, this hardware going to be supported in mainline Linux, too. > > How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? > > I'd like to see this change be submitted to Linux first, or else have an > explanation of why a divergence for U-Boot is warranted. Thanks. Wolfgang Denk
On Wednesday, September 21, 2011 10:16:35 PM Wolfgang Denk wrote: > Dear Stefano & Marek, > > can you please provide the requested information? > > In message <4E7A4145.30501@freescale.com> Scott Wood wrote: > > > In message <4E7A320D.1030002@freescale.com> you wrote: > > >> Is this hardware going to be supported in Linux? It would be nice if > > >> we could keep this code in sync. > > > > > > Stefano has submitted patches for the iMX28 based M28 / M28EVK board, > > > so yes, this hardware going to be supported in mainline Linux, too. > > > > How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? > > > > I'd like to see this change be submitted to Linux first, or else have an > > explanation of why a divergence for U-Boot is warranted. > > Thanks. > > Wolfgang Denk This patch is actually optional and right now isn't used by M28. Though someone might find this helpful. Cheers
On 09/21/2011 10:16 PM, Wolfgang Denk wrote: > Dear Stefano & Marek, > > can you please provide the requested information? > > Hi Scott, > In message <4E7A4145.30501@freescale.com> Scott Wood wrote: >> >>> In message <4E7A320D.1030002@freescale.com> you wrote: >>>> >>>> Is this hardware going to be supported in Linux? It would be nice if we >>>> could keep this code in sync. >>> >>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board, >>> so yes, this hardware going to be supported in mainline Linux, too. >> >> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? >> >> I'd like to see this change be submitted to Linux first, or else have an >> explanation of why a divergence for U-Boot is warranted. I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije: http://www.spinics.net/lists/arm-kernel/msg139526.html However, I have not seen the option NAND_OWN_BUFFERS in his patches. Best regards, Stefano
On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote: > On 09/21/2011 10:16 PM, Wolfgang Denk wrote: > > Dear Stefano & Marek, > > > > can you please provide the requested information? > > Hi Scott, > > > In message <4E7A4145.30501@freescale.com> Scott Wood wrote: > >>> In message <4E7A320D.1030002@freescale.com> you wrote: > >>>> Is this hardware going to be supported in Linux? It would be nice if > >>>> we could keep this code in sync. > >>> > >>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board, > >>> so yes, this hardware going to be supported in mainline Linux, too. > >> > >> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? > >> > >> I'd like to see this change be submitted to Linux first, or else have an > >> explanation of why a divergence for U-Boot is warranted. > > I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije: > > http://www.spinics.net/lists/arm-kernel/msg139526.html > > However, I have not seen the option NAND_OWN_BUFFERS in his patches. > > Best regards, > Stefano Like I said, this patch is not needed anymore. It's just a convenience measure now. I don't need to for mx28.
On 09/22/2011 03:51 AM, Marek Vasut wrote: > On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote: >> On 09/21/2011 10:16 PM, Wolfgang Denk wrote: >>> Dear Stefano & Marek, >>> >>> can you please provide the requested information? >> >> Hi Scott, >> >>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote: >>>>> In message <4E7A320D.1030002@freescale.com> you wrote: >>>>>> Is this hardware going to be supported in Linux? It would be nice if >>>>>> we could keep this code in sync. >>>>> >>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board, >>>>> so yes, this hardware going to be supported in mainline Linux, too. >>>> >>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? >>>> >>>> I'd like to see this change be submitted to Linux first, or else have an >>>> explanation of why a divergence for U-Boot is warranted. >> >> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije: >> >> http://www.spinics.net/lists/arm-kernel/msg139526.html >> >> However, I have not seen the option NAND_OWN_BUFFERS in his patches. >> >> Best regards, >> Stefano > > Like I said, this patch is not needed anymore. It's just a convenience measure > now. I don't need to for mx28. > Let's hold off on this patch until it's actually needed, then. -Scott
On Friday, September 23, 2011 07:35:15 PM Scott Wood wrote: > On 09/22/2011 03:51 AM, Marek Vasut wrote: > > On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote: > >> On 09/21/2011 10:16 PM, Wolfgang Denk wrote: > >>> Dear Stefano & Marek, > >>> > >>> can you please provide the requested information? > >> > >> Hi Scott, > >> > >>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote: > >>>>> In message <4E7A320D.1030002@freescale.com> you wrote: > >>>>>> Is this hardware going to be supported in Linux? It would be nice > >>>>>> if we could keep this code in sync. > >>>>> > >>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board, > >>>>> so yes, this hardware going to be supported in mainline Linux, too. > >>>> > >>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? > >>>> > >>>> I'd like to see this change be submitted to Linux first, or else have > >>>> an explanation of why a divergence for U-Boot is warranted. > >> > >> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije: > >> http://www.spinics.net/lists/arm-kernel/msg139526.html > >> > >> However, I have not seen the option NAND_OWN_BUFFERS in his patches. > >> > >> Best regards, > >> Stefano > > > > Like I said, this patch is not needed anymore. It's just a convenience > > measure now. I don't need to for mx28. > > Let's hold off on this patch until it's actually needed, then. Very well then, mind merging the rest then ? Cheers > > -Scott
On 09/24/2011 07:37 AM, Marek Vasut wrote: > On Friday, September 23, 2011 07:35:15 PM Scott Wood wrote: >> On 09/22/2011 03:51 AM, Marek Vasut wrote: >>> On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote: >>>> On 09/21/2011 10:16 PM, Wolfgang Denk wrote: >>>>> Dear Stefano & Marek, >>>>> >>>>> can you please provide the requested information? >>>> >>>> Hi Scott, >>>> >>>>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote: >>>>>>> In message <4E7A320D.1030002@freescale.com> you wrote: >>>>>>>> Is this hardware going to be supported in Linux? It would be nice >>>>>>>> if we could keep this code in sync. >>>>>>> >>>>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK board, >>>>>>> so yes, this hardware going to be supported in mainline Linux, too. >>>>>> >>>>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? >>>>>> >>>>>> I'd like to see this change be submitted to Linux first, or else have >>>>>> an explanation of why a divergence for U-Boot is warranted. >>>> >>>> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije: >>>> http://www.spinics.net/lists/arm-kernel/msg139526.html >>>> >>>> However, I have not seen the option NAND_OWN_BUFFERS in his patches. >>>> >>>> Best regards, >>>> Stefano >>> >>> Like I said, this patch is not needed anymore. It's just a convenience >>> measure now. I don't need to for mx28. >> >> Let's hold off on this patch until it's actually needed, then. > > Very well then, mind merging the rest then ? Yes, I'll try to get to it soon. -Scott
On Monday, September 26, 2011 08:33:56 PM Scott Wood wrote: > On 09/24/2011 07:37 AM, Marek Vasut wrote: > > On Friday, September 23, 2011 07:35:15 PM Scott Wood wrote: > >> On 09/22/2011 03:51 AM, Marek Vasut wrote: > >>> On Thursday, September 22, 2011 09:41:21 AM Stefano Babic wrote: > >>>> On 09/21/2011 10:16 PM, Wolfgang Denk wrote: > >>>>> Dear Stefano & Marek, > >>>>> > >>>>> can you please provide the requested information? > >>>> > >>>> Hi Scott, > >>>> > >>>>> In message <4E7A4145.30501@freescale.com> Scott Wood wrote: > >>>>>>> In message <4E7A320D.1030002@freescale.com> you wrote: > >>>>>>>> Is this hardware going to be supported in Linux? It would be nice > >>>>>>>> if we could keep this code in sync. > >>>>>>> > >>>>>>> Stefano has submitted patches for the iMX28 based M28 / M28EVK > >>>>>>> board, so yes, this hardware going to be supported in mainline > >>>>>>> Linux, too. > >>>>>> > >>>>>> How do the Linux iMX28 patches deal with NAND_OWN_BUFFERS? > >>>>>> > >>>>>> I'd like to see this change be submitted to Linux first, or else > >>>>>> have an explanation of why a divergence for U-Boot is warranted. > >>>> > >>>> I tested NAND with the gpmi-nand patches sent to linux-arm by Huang Shije: > >>>> http://www.spinics.net/lists/arm-kernel/msg139526.html > >>>> > >>>> However, I have not seen the option NAND_OWN_BUFFERS in his patches. > >>>> > >>>> Best regards, > >>>> Stefano > >>> > >>> Like I said, this patch is not needed anymore. It's just a convenience > >>> measure now. I don't need to for mx28. > >> > >> Let's hold off on this patch until it's actually needed, then. > > > > Very well then, mind merging the rest then ? > > Yes, I'll try to get to it soon. Thanks Scott, and thanks for your patience while reviewing, I know I had my moments where I wasn't too nice / was whiny ;-) Cheers > > -Scott
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index d8d30e3..3093067 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2749,13 +2749,27 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips, */ int nand_scan_tail(struct mtd_info *mtd) { - int i; + int i, bufsize; + uint8_t *buf; struct nand_chip *chip = mtd->priv; - if (!(chip->options & NAND_OWN_BUFFERS)) - chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL); - if (!chip->buffers) - return -ENOMEM; + if (!(chip->options & NAND_OWN_BUFFERS)) { + chip->buffers = malloc(sizeof(struct nand_buffers)); + if (!chip->buffers) + return -ENOMEM; + + bufsize = NAND_MAX_PAGESIZE + (3 * NAND_MAX_OOBSIZE); + buf = malloc(bufsize); + if (!buf) { + free(chip->buffers); + return -ENOMEM; + } + + chip->buffers->buffer = buf; + chip->buffers->ecccalc = buf; + chip->buffers->ecccode = buf + NAND_MAX_OOBSIZE; + chip->buffers->databuf = buf + (2 * NAND_MAX_OOBSIZE); + } /* Set the internal oob buffer location, just after the page data */ chip->oob_poi = chip->buffers->databuf + mtd->writesize; @@ -2996,6 +3010,8 @@ void nand_release(struct mtd_info *mtd) /* Free bad block table memory */ kfree(chip->bbt); - if (!(chip->options & NAND_OWN_BUFFERS)) - kfree(chip->buffers); + if (!(chip->options & NAND_OWN_BUFFERS)) { + free(chip->buffers->buffer); + free(chip->buffers); + } } diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 987a2ec..c3449a9 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -370,9 +370,10 @@ struct nand_ecc_ctrl { * consecutive order. */ struct nand_buffers { - uint8_t ecccalc[NAND_MAX_OOBSIZE]; - uint8_t ecccode[NAND_MAX_OOBSIZE]; - uint8_t databuf[NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE]; + uint8_t *buffer; + uint8_t *ecccalc; + uint8_t *ecccode; + uint8_t *databuf; }; /**
Don't allocate NAND buffers as one block, but allocate them separately. This allows systems where DMA to buffers happen to allocate these buffers properly aligned. Signed-off-by: Marek Vasut <marek.vasut@gmail.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: Detlev Zundel <dzu@denx.de> --- drivers/mtd/nand/nand_base.c | 30 +++++++++++++++++++++++------- include/linux/mtd/nand.h | 7 ++++--- 2 files changed, 27 insertions(+), 10 deletions(-)