[PATCH v4 0/7] mtd: spi-nor: add a new framework for SPI NOR

[Jagan Teki]

On Fri, Jan 17, 2014 at 7:32 AM, Huang Shijie <b32955 at freescale.com> wrote:
> On Thu, Jan 16, 2014 at 03:09:13PM +0530, Jagan Teki wrote:
>> >>>     After this patch, the layer is like:
>> >>>                     MTD
>> >>>           ------------------------
>> >>>                    spi-nor
>> >>>           ------------------------
>> >>>                    m25p80
>> >>>           ------------------------
>> >>>                 spi bus driver
>> >>>           ------------------------
>> >>>                 SPI NOR chip
>>
>> Just for looking on your new framework, is that above link correct.
>> I guess it should be MTD -- m25p80 -- spi-nor -- spi bus driver -- SPI NOR chip
>
> I do not think so.
> The spi-nor layer does not contact with the spi bus driver directly.

Yes - now I understand the flow from seeing the code.
With your new framework
1. not an exact spi-nor
    have one controller driver at drivers/spi/* will register to spi core.
    have m25p80.c will scan the flash details from
drivers/mtd/spi-nor/spi-nor.c and
    m25p80 will register the MTD core and for transfer calls m25p80
will calls spi core.
2. spi-nor style
    have  one controller driver at drivers/mtd/spi-nor/fsl-quadspi.c
will register MTD core
    and scan the flash details from drivers/mtd/spi-nor/spi-nor.c and
for transfer will calls
    through direct writel and readl with cmd+data fashion.

Correct me If my understanding was wrong.
>
>> >> 3) Can you explain your framework precisely take an example of like
>> >> spi_controller_A with spi_flash_A
>> >> and qspi_controller_B and qspi_flash_B - how will this new framework
>> >> operates.
>> >>
>> > The framework is just cloned from the m25p80.c, and extract the common code,
>> > and provides more
>> > hooks such as
>> >
>> > @prepare/unpreare: used to do some work before or after the
>> >              read/write/erase/lock/unlock.
>> >     @read_xfer/write_xfer: We can use these two hooks to code all
>> >              the following hooks if the driver tries to implement them
>> >              by itself.
>> >     @read_reg: used to read the registers, such as read status register,
>> >              read configure register.
>> >     @write_reg: used to write the registers, such as write enable,
>> >              erase sector.
>> >     @read_id: read out the ID info.
>> >     @wait_till_ready: wait till the NOR becomes ready.
>> >     @read: read out the data from the NOR.
>> >     @write: write data to the NOR.
>> >     @erase: erase a sector of the NOR.
>> >
>>
>> My basic question is like I have a qspi spi controller in my SOC and I
>> designed two boards B1 and B2
>
> okay.
>
>> B1 with quad spi controller connected with non-flash as a slave and B2
>> with quad spi controller connected
>> with quad flash as a slave.
> You can use the framework for B2. But for B1, you should not use the framework,
> since this framework is just for the SPI-NOR. If you do not connected with
> a NOR, i think it's better to code another driver for your controller.

Means we have two separate controller drivers for same controller one
with spi-nor and
another with spi is it?

Do you think this is a good idea, I understand you have a complete and
well guided new
spi-nor framework.

-- 
Thanks,
Jagan.