[PATCH v6 11/15] nand: spi: add basic operations support

Peter Pan 潘栋 (peterpandong) peterpandong at micron.com
Wed Jun 28 23:07:51 PDT 2017


Hi Boris,

> 在 2017年6月28日,04:16,Boris Brezillon <boris.brezillon at free-electrons.com> 写道:
> 
> 
>>>> 
>>>> diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
>>>> index dd9da71..04ad1dd 100644
>>>> --- a/include/linux/mtd/spinand.h
>>>> +++ b/include/linux/mtd/spinand.h
>>>> @@ -103,11 +103,14 @@ struct spinand_controller_ops {
>>>> *          return directly and let others to detect.
>>>> * @init: initialize SPI NAND device.
>>>> * @cleanup: clean SPI NAND device footprint.
>>>> + * @prepare_op: prepara read/write operation.  
>>> 
>>>          ^ prepare
>>> 
>>> 
>>> 
>>>> */
>>>> struct spinand_manufacturer_ops {
>>>>   bool (*detect)(struct spinand_device *spinand);
>>>>   int (*init)(struct spinand_device *spinand);
>>>>   void (*cleanup)(struct spinand_device *spinand);
>>>> +    void (*prepare_op)(struct spinand_device *spinand,
>>>> +               struct spinand_op *op, u32 page, u32 column);  
>>> 
>>> It seems to be here to prepare read/write page operations, so I'd like
>>> to rename this method ->prepare_page_op() if you don't mind.  
>> 
>> I'm ok with the new name
> 
> Hm, actually I wonder if this ->prepare_op() method is really what we
> want. It seems to be here to set the proper plane number and the
> number of dummy bytes after the address cycles.
> I'd say deducing the plane from the page is something standard. Whether
> we need it or not depends on the information provide in the memorg
> object (->nplanes).

For Micron spi nand, it's true. But I don't know whether other vendors'
spi nand need set plane number when the chip has more than one
planes. The reason Micron spi nand need to set plane number is
internal cache register is per plane.

Arnaud,
Do you have info about this?

Thanks 
Peter Pan 

> 
> Regarding the dummy byte, do you have examples of SPI NANDs requiring
> less or more dummy bytes in this read/write from/to cache use case?
> If not, I'd prefer to keep it hardcoded in the core for know, and add
> a hook when the need appears.


More information about the linux-mtd mailing list