[PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND controller

Liu Shengzhou-B36685 B36685 at freescale.com
Wed Dec 7 14:16:53 EST 2011


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, December 07, 2011 1:17 AM
> To: Liu Shengzhou-B36685
> Cc: linuxppc-dev at lists.ozlabs.org; linux-mtd at lists.infradead.org;
> dwmw2 at infradead.org; Gala Kumar-B11780
> Subject: Re: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND
> controller
> 
> On 12/06/2011 02:54 AM, Shengzhou Liu wrote:
> > diff --git a/drivers/mtd/nand/fsl_elbc_nand.c
> b/drivers/mtd/nand/fsl_elbc_nand.c
> > index 4f405a0..b4db407 100644
> > --- a/drivers/mtd/nand/fsl_elbc_nand.c
> > +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> > @@ -349,19 +349,24 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd,
> unsigned int command,
> >  		fsl_elbc_run_command(mtd);
> >  		return;
> >
> > -	/* READID must read all 5 possible bytes while CEB is active */
> >  	case NAND_CMD_READID:
> > -		dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD_READID.\n");
> > +	case NAND_CMD_PARAM:
> > +		dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD %x\n",
> command);
> >
> >  		out_be32(&lbc->fir, (FIR_OP_CM0 << FIR_OP0_SHIFT) |
> >  		                    (FIR_OP_UA  << FIR_OP1_SHIFT) |
> >  		                    (FIR_OP_RBW << FIR_OP2_SHIFT));
> > -		out_be32(&lbc->fcr, NAND_CMD_READID << FCR_CMD0_SHIFT);
> > -		/* nand_get_flash_type() reads 8 bytes of entire ID string */
> > -		out_be32(&lbc->fbcr, 8);
> > -		elbc_fcm_ctrl->read_bytes = 8;
> > +		out_be32(&lbc->fcr, command << FCR_CMD0_SHIFT);
> > +		/* reads 8 bytes of entire ID string */
> > +		if (NAND_CMD_READID == command) {
> 
> if (command == NAND_CMD_READID) {
> 
> > +			out_be32(&lbc->fbcr, 8);
> > +			elbc_fcm_ctrl->read_bytes = 8;
> > +		} else {
> > +			out_be32(&lbc->fbcr, 256);
> > +			elbc_fcm_ctrl->read_bytes = 256;
> > +		}
> 
> Any harm in always using 256?
> 
> -Scott
[Shengzhou] For NAND_CMD_READID command, the total bytes of entire ID string are 8, there are not 256 bytes so many, it's unnecessary and looks not so well logically to always using 256, though it works.




More information about the Linuxppc-dev mailing list