[RFC] How to configure nand address cycles in a generic way

[RFC] How to configure nand address cycles in a generic way

[punnaiah choudary kalluri]

Hi,

  We are using pl353 smc controller in our zynq soc and currently the
patches for this driver
are under review. Till now we have tested various nand parts (micron
and spansion)
and all these devices require five address cycles for read/write
operations (3 row and 2 column address cycles).Even in our driver the
address cycles value is hard coded to five.

   Recently we come across testing the new part i.e Spansion S34ML01G
and this devices requires four address cycles( 2 row and 2 column
cycles) so, now we want to generalize this by reading the address
cycles information from the onfi parameter page.

 I see that the controller driver can retrieve the address cycles
information from the nand_onfi_params structure. But the number of
address cycles to be configured is different for different commands.
like
 Page read/write operation: row + col address cycles
 Block erase                    : row address cycles
 onfi parameter page         : one address cycles.

Currently in our driver we are reading the address cycles information
from the nand_onfi_params structure and deriving the required address
cycles based on the given command. Ideally this information should
come from the nand core. So, one way i thought that the core should
pass the
required address cycles using the cmdfuncion as below. so the
controller driver can blindly program this information to the
controller.

void (*cmdfunc)(struct mtd_info *mtd, unsigned command, int column,
                             int page_addr, int address_cycles);

Please suggest is there any better solution to handle this case ?


Regards,
Punnaiah

Re: [RFC] How to configure nand address cycles in a generic way

[Boris Brezillon]

Hi Punnaiah,

On Wed, 25 Feb 2015 21:14:06 +0530
punnaiah choudary kalluri <punnaia@xilinx.com> wrote:

> Hi,
> 
>   We are using pl353 smc controller in our zynq soc and currently the
> patches for this driver
> are under review. Till now we have tested various nand parts (micron
> and spansion)
> and all these devices require five address cycles for read/write
> operations (3 row and 2 column address cycles).Even in our driver the
> address cycles value is hard coded to five.
> 
>    Recently we come across testing the new part i.e Spansion S34ML01G
> and this devices requires four address cycles( 2 row and 2 column
> cycles) so, now we want to generalize this by reading the address
> cycles information from the onfi parameter page.

That's expected.
NAND with 'big pages' (> 512 bytes) and size < 128MB only require 4
address cycles (see nand_base implementation of cmdfunc [1]).

> 
>  I see that the controller driver can retrieve the address cycles
> information from the nand_onfi_params structure. But the number of
> address cycles to be configured is different for different commands.
> like
>  Page read/write operation: row + col address cycles
>  Block erase                    : row address cycles
>  onfi parameter page         : one address cycles.
> 
> Currently in our driver we are reading the address cycles information
> from the nand_onfi_params structure and deriving the required address
> cycles based on the given command. Ideally this information should
> come from the nand core. So, one way i thought that the core should
> pass the
> required address cycles using the cmdfuncion as below. so the
> controller driver can blindly program this information to the
> controller.
> 
> void (*cmdfunc)(struct mtd_info *mtd, unsigned command, int column,
>                              int page_addr, int address_cycles);
> 
> Please suggest is there any better solution to handle this case ?

Actually I worked on a similar patch but for different reasons: most
controllers are now handling full NAND operations (cmd + addr cycles +
data transfer), but the framework kind of force the cmd + addr cycles
and data transfer separation.
We could benefit from the performance improvement induced by this single
NAND operation step (you wait for the whole operation to finish
instead of waking the thread several times to handle each step).
Note that some drivers are already implementing this logic internally.

My idea is to add an ->opfunc() callback that is called in place of the
->cmdfunc() + ->read/write_buf() sequence.

Here is the status of my work [2].

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_base.c#L714
[2]http://code.bulix.org/9askmm-87977


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com