Aw: Re: Hardware ECC in NAND flash driver

Aw: Re: Hardware ECC in NAND flash driver

[tglx]

Steven Hein <ssh@sgi.com> wrote:
> This all looks great!
:):):) 

> Sounds good.
:):):) 

> > The funtion, which does correct_data calculations for the specfic
> > hardware ecc should be implemented as a general function in 
> nand_ecc.c> to make it usable for similar hardware drivers and to 
> avoid duplicated
> > code in these drivers.
> 
> Dumb question--is ECC calculation "generic" enough to be 
> applicable from
> one hardware ECC generator to the next, even if they do the same 
> numberof ECC bytes for the same block size?  Is it very likely 
> that the
> algorithm
> is actually going to be the same between platforms?
I think so, because  Samsung and others will bring up similar chips, 
which 
incorporate the same ECC generator, but with maybe different registers 
or
opcodes. But the algorithm will be the same for interdevice compability. 
So
IMHO it's correct to put it in the generic nand_ecc code.
 
> THANKS for adding this!!  I'll try it today/tomorrow.
I'm curious, how many bugs you will detect. :)
 
> Another question--how do you typically handle adding new HW drivers
> to the NAND flash code?  I know that in my case, the HW implementation
> uses access to specific S3C2410 processor registers, and those
> register definitions live in include/asm-arm/arch-s3c2410 directory
> in the Linux kernel tree.  I would expect that these arch-specific
> files would not live in the MTD tree.  Let me know--I'd like to get
> this HW driver incorporated into the standard tree as soon as I
> get it working!

That's easy, you include <asm/hardware.h> and you should be done. When 
your
driver is ready, let me know. I will take care for incorporation.
 
Thomas

Re: Aw: Re: Hardware ECC in NAND flash driver

[Steven Hein]

tglx@linutronix.de wrote:
> >
> > Dumb question--is ECC calculation "generic" enough to be
> > applicable from
> > one hardware ECC generator to the next, even if they do the same
> > numberof ECC bytes for the same block size?  Is it very likely
> > that the
> > algorithm
> > is actually going to be the same between platforms?
> I think so, because  Samsung and others will bring up similar chips,
> which
> incorporate the same ECC generator, but with maybe different registers
> or
> opcodes. But the algorithm will be the same for interdevice compability.
> So
> IMHO it's correct to put it in the generic nand_ecc code.
> 

Sounds fine with me!

Any preference on how the correct_data function should be named
(the one I should add to nand_ecc.c)?  Let me know what you'd prefer
and I'll use that name from the start.

> > THANKS for adding this!!  I'll try it today/tomorrow.
> I'm curious, how many bugs you will detect. :)
> 

The final tally is.......ZERO!!  I tried it and it worked great.
Thanks again!


> > Another question--how do you typically handle adding new HW drivers
> > to the NAND flash code?  I know that in my case, the HW implementation
> > uses access to specific S3C2410 processor registers, and those
> > register definitions live in include/asm-arm/arch-s3c2410 directory
> > in the Linux kernel tree.  I would expect that these arch-specific
> > files would not live in the MTD tree.  Let me know--I'd like to get
> > this HW driver incorporated into the standard tree as soon as I
> > get it working!
> 
> That's easy, you include <asm/hardware.h> and you should be done. When
> your
> driver is ready, let me know. I will take care for incorporation.
> 
I'll let you know when I have it done  (I'm working with a Samsung
employee on the 2410 port; when we get it cleaned up I'll
send it to you).


Steve



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~