Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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.30...@freescale.com> Scott Wood wrote: > >>> In message <4e7a320d.1030...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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.30...@freescale.com> Scott Wood wrote: >>> In message <4e7a320d.1030...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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.30...@freescale.com> Scott Wood wrote: > > In message <4e7a320d.1030...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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.30...@freescale.com> Scott Wood wrote: > In message <4e7a320d.1030...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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.30...@freescale.com> Scott Wood wrote: > >>> In message <4e7a320d.1030...@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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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.30...@freescale.com> Scott Wood wrote: >> >>> In message <4e7a320d.1030...@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 -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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.30...@freescale.com> Scott Wood wrote: > > > In message <4e7a320d.1030...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
Dear Stefano & Marek, can you please provide the requested information? In message <4e7a4145.30...@freescale.com> Scott Wood wrote: > > > In message <4e7a320d.1030...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, "Assignment: Earth", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
On 09/21/2011 02:49 PM, Wolfgang Denk wrote: > Dear Scott Wood, > > In message <4e7a320d.1030...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
Dear Scott Wood, In message <4e7a320d.1030...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Mr. Cole's Axiom: The sum of the intelligence on the planet is a constant; the population is growing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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 > Cc: Scott Wood > Cc: Stefano Babic > Cc: Wolfgang Denk > Cc: Detlev Zundel > --- > 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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
Cc: Scott Wood
Cc: Stefano Babic
Cc: Wolfgang Denk
Cc: Detlev Zundel
---
drivers/mtd/nand/nand_base.c | 30 +++---
include/linux/mtd/nand.h |7 ---
2 files changed, 27 insertions(+), 10 deletions(-)
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;
};
/**
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] NAND: Allow per-buffer allocation
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
Cc: Scott Wood
Cc: Stefano Babic
Cc: Wolfgang Denk
Cc: Detlev Zundel
---
drivers/mtd/nand/nand_base.c | 30 +++---
include/linux/mtd/nand.h |7 ---
2 files changed, 27 insertions(+), 10 deletions(-)
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;
};
/**
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
