David, I am able to support up to 4K page size in the DaVinci nand driver, without any change to the include/mtd/mtd-abi.h (would break user-space ioctl interface).
The structure .eccpos is not used by the ECC_SYNDROME mode and thus we do not need to extend it for 4K page size ecc positions. However oobavail is used in some of the oob APIs and we already have support for 8 entries - required by the 4K page. But the "for loop" below has be changed to restrict it from going beyond the array limit as well as ecc.steps (to make sure it is still backward compatible with 2K page size). The onenand_base.c file which is based on nand_base.c of the nand driver has already fixed this array limit issue. I am going through some testing now and should be able to post the patches later today. Thanks Sneha > -----Original Message----- > From: davinci-linux-open-source- > [email protected] [mailto:davinci-linux- > [email protected]] On Behalf Of > Narnakaje, Snehaprabha > Sent: Wednesday, March 25, 2009 5:10 PM > To: David Brownell > Cc: [email protected] > Subject: RE: [PATCH 1/3] MTD-NAND: Add support NAND devices up to 4K page > size and 128bytes OOB > > > > > -----Original Message----- > > From: David Brownell [mailto:[email protected]] > > Sent: Wednesday, March 25, 2009 4:26 PM > > To: Narnakaje, Snehaprabha > > Cc: [email protected] > > Subject: Re: [PATCH 1/3] MTD-NAND: Add support NAND devices up to 4K > page > > size and 128bytes OOB > > > > On Wednesday 25 March 2009, Narnakaje, Snehaprabha wrote: > > > Unfortunately .eccpos is being used in the latest kernels > > > (as against 2.6.10/2.6.18) to calculate .oobavail in the > > > nand_base.c > > > > In 2.6.29 I see: > > > > /* > > * The number of bytes available for a client to place data into > > * the out of band area > > */ > > chip->ecc.layout->oobavail = 0; > > for (i = 0; chip->ecc.layout->oobfree[i].length; i++) > > chip->ecc.layout->oobavail += > > chip->ecc.layout->oobfree[i].length; > > mtd->oobavail = chip->ecc.layout->oobavail; > > > > So I don't quite follow ... > > You are right, .eccpos it not a problem here. The .eccpos is used in the > default hwecc and swecc read_page/write_page/subpage APIs. For davinci- > nand, we override these APIs. For davinci, I can test without the change > to eccpos[] and see if it works (should). But it may be a problem in > general for 4K page size support, if there are other boards requiring to > use hwecc and swecc APIs. > > I guess, I also wanted to bring up another related problem with the patch > I submitted. I happen to change MTD_MAX_OOBFREE_ENTRIES to 16 from 8 and > that is used by oobfree in that structure. Wouldn't that also create a > problem for the IOCTL and existing binaries? > > The above code for calculating oobavail uses the oobfree[].length and in > our case we exactly have 8 for a 4K page. But the way above code tries to > come out of the for loop is based on the length being zero ('i' could go > beyond the array limit). May be we can change this for loop and avoid > change to the macro below. > > -#define MTD_MAX_OOBFREE_ENTRIES 8 > +#define MTD_MAX_OOBFREE_ENTRIES 16 > /* > * ECC layout control structure. Exported to userspace for > * diagnosis and to allow creation of raw images > */ > struct nand_ecclayout { > uint32_t eccbytes; > - uint32_t eccpos[64]; > + uint32_t eccpos[128]; > uint32_t oobavail; > struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES]; > }; > > > Thanks > Sneha > > > > > > > > If we can come up with another method to calculate .oobavail, > > > we could just leave the nand_ecclayout as is (similar to what > > > happened with nand_oobinfo) > > > > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
