On Fri, May 2, 2008 at 5:22 AM, Wolfgang Denk wd@denx.de wrote:
In message 1209671826-31404-1-git-send-email-plagnioj@jcrosoft.com you wrote:
by Align with word(16-bit) size as done in Linux
in
- onenand_read_bufferram
- onenand_sync_read_bufferram
- onenand_write_bufferram
This is much more intrusive than the simple rename patch; I suggest we do the rename now to fix the immediate compile problem, and wait with this more complex patch for the next merge window.
static const unsigned char ffchars[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 16 */ @@ -358,6 +345,17 @@ static int onenand_read_bufferram(struct mtd_info *mtd, int area, bufferram = this->base + area; bufferram += onenand_bufferram_offset(mtd, area);
if (ONENAND_CHECK_BYTE_ACCESS(count)) {unsigned short word;/* Align with word(16-bit) size */count--;/* Read word and save byte */word = this->read_word(bufferram + offset + count);buffer[count] = (word & 0xff);
No, No, It doesn't handle the current OneNAND access. Now it received the 4-byte aligned address. So it's not triggered.
The best is #define __ARCH_HAVE_MEMCPY32, 32 bytes aligned memcpy. or the previous patch memcpy_16 is second one.
Thank you, Kyungmin Park