Message ID | 1321349355-1639-2-git-send-email-b35362@freescale.com |
---|---|
State | New, archived |
Headers | show |
On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote: > From: Liu Shuo <b35362@freescale.com> > > If we use the Nand flash chip whose number of pages in a block is greater > than 64(for large page), we must treat the low bit of FBAR as being the > high bit of the page address due to the limitation of FCM, it simply uses > the low 6-bits (for large page) of the combined block/page address as the > FPAR component, rather than considering the actual block size. Looks like this patch depends on the previous white-space clean-up patch - could you please refactor it (and 3/3 too) and resend? Artem.
Ok and I want to add another patch before 3/3. -LiuShuo > On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote: >> From: Liu Shuo<b35362@freescale.com> >> >> If we use the Nand flash chip whose number of pages in a block is greater >> than 64(for large page), we must treat the low bit of FBAR as being the >> high bit of the page address due to the limitation of FCM, it simply uses >> the low 6-bits (for large page) of the combined block/page address as the >> FPAR component, rather than considering the actual block size. > Looks like this patch depends on the previous white-space clean-up patch > - could you please refactor it (and 3/3 too) and resend? Ok and I am going to add another new patch before 3/3. -LiuShuo > Artem. > >
On Fri, 2011-11-18 at 10:08 +0800, LiuShuo wrote: > Ok and I want to add another patch before 3/3. > > -LiuShuo > > On Tue, 2011-11-15 at 17:29 +0800, b35362@freescale.com wrote: > >> From: Liu Shuo<b35362@freescale.com> > >> > >> If we use the Nand flash chip whose number of pages in a block is greater > >> than 64(for large page), we must treat the low bit of FBAR as being the > >> high bit of the page address due to the limitation of FCM, it simply uses > >> the low 6-bits (for large page) of the combined block/page address as the > >> FPAR component, rather than considering the actual block size. > > Looks like this patch depends on the previous white-space clean-up patch > > - could you please refactor it (and 3/3 too) and resend? > Ok and I am going to add another new patch before 3/3. Sure, send 3/3 as well because this one depends on the cleanup patch, so cannot be applied independently. Artem.
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index 1bfcdef..c2c231b 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -166,15 +166,22 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob) elbc_fcm_ctrl->page = page_addr; - out_be32(&lbc->fbar, - page_addr >> (chip->phys_erase_shift - chip->page_shift)); - if (priv->page_size) { + /* + * large page size chip : FPAR[PI] save the lowest 6 bits, + * FBAR[BLK] save the other bits. + */ + out_be32(&lbc->fbar, page_addr >> 6); out_be32(&lbc->fpar, ((page_addr << FPAR_LP_PI_SHIFT) & FPAR_LP_PI) | (oob ? FPAR_LP_MS : 0) | column); buf_num = (page_addr & 1) << 2; } else { + /* + * small page size chip : FPAR[PI] save the lowest 5 bits, + * FBAR[BLK] save the other bits. + */ + out_be32(&lbc->fbar, page_addr >> 5); out_be32(&lbc->fpar, ((page_addr << FPAR_SP_PI_SHIFT) & FPAR_SP_PI) | (oob ? FPAR_SP_MS : 0) | column);