Patchwork [U-Boot,3/5] NAND: Allow per-buffer allocation

login
register
mail settings
Submitter Marek Vasut
Date Sept. 12, 2011, 4:04 a.m.
Message ID <1315800250-19761-4-git-send-email-marek.vasut@gmail.com>
Download mbox | patch
Permalink /patch/114263/
State Deferred
Delegated to: Scott Wood
Headers show

Comments

Marek Vasut - Sept. 12, 2011, 4:04 a.m.
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(-)
Scott Wood - Sept. 21, 2011, 6:50 p.m.
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
Wolfgang Denk - Sept. 21, 2011, 7:49 p.m.
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
Scott Wood - Sept. 21, 2011, 7:55 p.m.
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
Wolfgang Denk - Sept. 21, 2011, 8:16 p.m.
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
Marek Vasut - Sept. 22, 2011, 1:34 a.m.
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
Stefano Babic - Sept. 22, 2011, 7:41 a.m.
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
Marek Vasut - Sept. 22, 2011, 8:51 a.m.
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.
Scott Wood - Sept. 23, 2011, 5:35 p.m.
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
Marek Vasut - Sept. 24, 2011, 12:37 p.m.
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
Scott Wood - Sept. 26, 2011, 6:33 p.m.
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
Marek Vasut - Sept. 26, 2011, 6:49 p.m.
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

Patch

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;
 };
 
 /**