[U-Boot] [PATCH] OneNAND: Fix compiler warnings and add weak attribute to memcpy_16()

[U-Boot] [PATCH] OneNAND: Fix compiler warnings and add weak attribute to memcpy_16()

[Stefan Roese]

This patch adds memcpy_16_from_onenand() and memcpy_16_to_onenand()
functions and defaults them to the already available memcpy_16()
function. They are defined weak so that they can be overwritten by
a board/platform specific version.

This is needed for the vcth board support (still to come) which needs
custom access routines here.

It also removes some compiler warnings by adding the onenand_get_2x_blockpage()
function and removing the onenand_lock()/onenand_unlock() functions.

Signed-off-by: Stefan Roese <sr@denx.de>
---

This patch has to be applied on top of the patch submitted by Kyungmin Park
on 2008-11-04:
[PATCH] [OneNAND] Sync with 2.6.27


 drivers/mtd/onenand/onenand_base.c |   38 ++++++++++++++++++++++++++++++++---
 1 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 66214e8..5c752ca 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -24,7 +24,7 @@
 #include <malloc.h>
 
 /* It should access 16-bit instead of 8-bit */
-static inline void *memcpy_16(void *dst, const void *src, unsigned int len)
+void *__memcpy_16(void *dst, const void *src, unsigned int len)
 {
 	void *ret = dst;
 	short *d = dst;
@@ -35,6 +35,10 @@ static inline void *memcpy_16(void *dst, const void *src, unsigned int len)
 		*d++ = *s++;
 	return ret;
 }
+void *memcpy_16_from_onenand(void *dst, const void *src, unsigned int len)
+	__attribute__((weak, alias("__memcpy_16")));
+void *memcpy_16_to_onenand(void *dst, const void *src, unsigned int len)
+	__attribute__((weak, alias("__memcpy_16")));
 
 static const unsigned char ffchars[] = {
 	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
@@ -349,7 +353,7 @@ static int onenand_read_bufferram(struct mtd_info *mtd, loff_t addr, int area,
 	bufferram = this->base + area;
 	bufferram += onenand_bufferram_offset(mtd, area);
 
-	memcpy_16(buffer, bufferram + offset, count);
+	memcpy_16_from_onenand(buffer, bufferram + offset, count);
 
 	return 0;
 }
@@ -376,7 +380,7 @@ static int onenand_sync_read_bufferram(struct mtd_info *mtd, loff_t addr, int ar
 
 	this->mmcontrol(mtd, ONENAND_SYS_CFG1_SYNC_READ);
 
-	memcpy_16(buffer, bufferram + offset, count);
+	memcpy_16_from_onenand(buffer, bufferram + offset, count);
 
 	this->mmcontrol(mtd, 0);
 
@@ -403,12 +407,36 @@ static int onenand_write_bufferram(struct mtd_info *mtd, loff_t addr, int area,
 	bufferram = this->base + area;
 	bufferram += onenand_bufferram_offset(mtd, area);
 
-	memcpy_16(bufferram + offset, buffer, count);
+	memcpy_16_to_onenand(bufferram + offset, buffer, count);
 
 	return 0;
 }
 
 /**
+ * onenand_get_2x_blockpage - [GENERIC] Get blockpage at 2x program mode
+ * @param mtd		MTD data structure
+ * @param addr		address to check
+ * @return		blockpage address
+ *
+ * Get blockpage address at 2x program mode
+ */
+static int onenand_get_2x_blockpage(struct mtd_info *mtd, loff_t addr)
+{
+	struct onenand_chip *this = mtd->priv;
+	int blockpage, block, page;
+
+	/* Calculate the even block number */
+	block = (int) (addr >> this->erase_shift) & ~1;
+	/* Is it the odd plane? */
+	if (addr & this->writesize)
+		block++;
+	page = (int) (addr >> (this->page_shift + 1)) & this->page_mask;
+	blockpage = (block << 7) | page;
+
+	return blockpage;
+}
+
+/**
  * onenand_check_bufferram - [GENERIC] Check BufferRAM information
  * @param mtd		MTD data structure
  * @param addr		address to check
@@ -1666,6 +1694,7 @@ static int onenand_do_lock_cmd(struct mtd_info *mtd, loff_t ofs, size_t len, int
 	return 0;
 }
 
+#ifdef ONENAND_LINUX
 /**
  * onenand_lock - [MTD Interface] Lock block(s)
  * @param mtd           MTD device structure
@@ -1701,6 +1730,7 @@ static int onenand_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
 	onenand_release_device(mtd);
 	return ret;
 }
+#endif
 
 /**
  * onenand_check_lock_status - [OneNAND Interface] Check lock status
-- 
1.6.0.3

[U-Boot] [PATCH] OneNAND: Fix compiler warnings and add weak attribute to memcpy_16()

[Scott Wood]

Stefan Roese wrote:
> This patch adds memcpy_16_from_onenand() and memcpy_16_to_onenand()
> functions and defaults them to the already available memcpy_16()
> function. They are defined weak so that they can be overwritten by
> a board/platform specific version.
> 
> This is needed for the vcth board support (still to come) which needs
> custom access routines here.

Can it just override write_bufferram and read_bufferram?  What does it 
need to do specially?

-Scott

[U-Boot] [PATCH] OneNAND: Fix compiler warnings and add weak attribute to memcpy_16()

[Stefan Roese]

On Friday 07 November 2008, Scott Wood wrote:
> Stefan Roese wrote:
> > This patch adds memcpy_16_from_onenand() and memcpy_16_to_onenand()
> > functions and defaults them to the already available memcpy_16()
> > function. They are defined weak so that they can be overwritten by
> > a board/platform specific version.
> >
> > This is needed for the vcth board support (still to come) which needs
> > custom access routines here.
>
> Can it just override write_bufferram and read_bufferram?

There are multiple functions here using this memcpy_16():

onenand_read_bufferram()
onenand_sync_read_bufferram()
onenand_write_bufferram()

So it seemed "easier" for me to just override the memcpy_16() function itself.

> What does it 
> need to do specially?

On our board the bufferram can't be accessed memory-mapped via pointer access. 
We need special accessor functions. Something like this:

/*
 * Accessor functions replacing the "weak" functions in
 * drivers/mtd/onenand/onenand_base.c
 */
void *memcpy_16_from_onenand(void *dst, const void *src, unsigned int len)
{
	void *ret = dst;
	u16 *d = dst;
	u16 *s = (u16 *)src;

	len >>= 1;
	while (len-- > 0)
		*d++ = ebi_nand_read_word(s++);

	return ret;
}


Best regards,
Stefan

=====================================================================
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: office at denx.de
=====================================================================

[U-Boot] [PATCH] OneNAND: Fix compiler warnings and add weak attribute to memcpy_16()

[Scott Wood]

Stefan Roese wrote:
> On Friday 07 November 2008, Scott Wood wrote:
>> Stefan Roese wrote:
>>> This is needed for the vcth board support (still to come) which needs
>>> custom access routines here.
>> Can it just override write_bufferram and read_bufferram?
> 
> There are multiple functions here using this memcpy_16():
> 
> onenand_read_bufferram()
> onenand_sync_read_bufferram()
> onenand_write_bufferram()
> 
> So it seemed "easier" for me to just override the memcpy_16() function itself.

onenand_read_bufferram and onenand_sync_read_bufferram are alternatives 
for the read_bufferram method; you don't need to provide both.  Thus, 
it's two method overrides versus two weak overrides.  Unless the board 
code doesn't know which of the two types of read will be used?

-Scott

[U-Boot] [PATCH] OneNAND: Fix compiler warnings and add weak attribute to memcpy_16()

[Stefan Roese]

On Monday 10 November 2008, Scott Wood wrote:
> >> Can it just override write_bufferram and read_bufferram?
> >
> > There are multiple functions here using this memcpy_16():
> >
> > onenand_read_bufferram()
> > onenand_sync_read_bufferram()
> > onenand_write_bufferram()
> >
> > So it seemed "easier" for me to just override the memcpy_16() function
> > itself.
>
> onenand_read_bufferram and onenand_sync_read_bufferram are alternatives
> for the read_bufferram method; you don't need to provide both.  Thus,
> it's two method overrides versus two weak overrides.  Unless the board
> code doesn't know which of the two types of read will be used?

Yes, you're right of course. I'll give it a try and send an updated patch (if 
needed) soon.

Thanks.

Best regards,
Stefan

=====================================================================
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: office at denx.de
=====================================================================