[U-Boot-Users] [PATCH 3/5] OneNAND support
Kyungmin Park
kmpark at infradead.org
Mon Sep 10 03:14:01 CEST 2007
> ...
> > +#ifdef __ARM__
> > +extern void memcpy32(void *, void *, size_t);
> > +
> > +static void *memcpy(void *dest, const void *src, size_t count)
> > +{
> > + if (count < 32) {
> > + unsigned short *_s = (unsigned short *)(src);
> > + unsigned short *_d = (unsigned short *)(dest);
> > + count >>= 1;
> > + while (count--)
> > + *_d++ = *_s++;
> > + return _d;
> > + }
> > +
> > + memcpy32(dest, (void *)src, count);
> > +
> > + return (void *)count;
> > +}
> > +#endif
>
> Why exactly do we need this? And why do we need an additonal special
> function memcpy32?
It's for performance. Now ARM used the char-based memcpy. Even though it's working with current char-based memcpy, I want to use the
optimized memcpy.
And basically OneNAND uses the 16-bit buswidth so we don't sure the correct behavior in OneNAND BufferRAM if we use the char-based
memcpy.
Memcpy32 is 32-bytes aligned optimized. Since we know the memcpy usages in OneNAND driver, we guarantee the usage of memcpy32.
>
> > +static const unsigned char ffchars[] = {
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 16 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 32 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 48 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 64 */
> > +};
>
> Using a dynamic buffer and a memset() call in the init code may helpt
> to reduce the memory footprint. What do you think?
At first I want to sync between the linux OneNAND code and u-boot one.
The current code of u-boot patch is the first implementation of linux OneNAND.
There are a lot of works to sync.
So after committing of patches, I will modify it.
>
> > +static unsigned short onenand_readw(void __iomem * addr)
> > +{
> > + return readw(addr);
> > +}
> ...
> > +static void onenand_writew(unsigned short value, void __iomem * addr)
> > +{
> > + writew(value, addr);
> > +}
>
> If this is all you do, you should probably use an inline or a macro.
It's same reason as above.
In linux OneNAND, we can overwrite the readw and writew. But I'm now sure it's needed at u-boot.
if (!this->read_word)
this->read_word = onenand_readw;
if (!this->write_word)
this->write_word = onenand_writew;
>
> > + * Get the device and lock it for exclusive access
> > + */
> > +static void onenand_get_device(struct mtd_info *mtd, int new_state)
> > +{
> > + /* Do nothing */
> > +}
> ...
> > + * Deselect, release chip lock and wake up anyone waiting on the device
> > + */
> > +static void onenand_release_device(struct mtd_info *mtd)
> > +{
> > + /* Do nothing */
> > +}
>
> Inline? Macro?
>
Also others are same. Some functions are don't needed at u-boot. But it was remained for easy adaptation from linux to u-boot.
Thank you,
Kyungmin Park
More information about the U-Boot
mailing list