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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Huang Shijie,

Thanks for your response, please see below.

On Thu, Jan 16, 2014 at 2:41 PM, Huang Shijie <b32955@xxxxxxxxxxxxx> wrote:
> 于 2014年01月16日 03:15, Jagan Teki 写道:
>
>> Hi,
>>
>> On Wed, Dec 25, 2013 at 11:20 AM, Huang Shijie<b32955@xxxxxxxxxxxxx>
>> wrote:
>>>
>>> 1.) Why add a new framework for SPI NOR?
>>>    The SPI-NOR controller such as Freescale's Quadspi controller is
>>> working
>>>    in a different way from the SPI bus. It should knows the NOR commands
>>> to
>>>    find the right LUT sequence. Unfortunately, the current code can not
>>> meet
>>>    this requirement.
>>>
>>> 2.) How does this patch set do?
>>>     This patch set adds a new spi-nor layer.
>>>     Before this patch, the layer is like:
>>>
>>>                     MTD
>>>           ------------------------
>>>                    m25p80
>>>           ------------------------
>>>                 spi bus driver
>>>           ------------------------
>>>                  SPI NOR chip
>>>
>>>     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

Because m25p80 will register to mtd core on top and will call spi core
data transfer.

Correct me if am wrong.

>>>
>>>    With the spi-nor controller driver(Freescale Quadspi), it looks like:
>>>                     MTD
>>>           ------------------------
>>>                    spi-nor
>>>           ------------------------
>>>                  fsl-quadspi
>>>           ------------------------
>>>                 SPI NOR chip
>>
>> I'm new to this thread, may be I'll ask basic questions.
>> 1) what does m25p80 contains with your new framework - will excludes
>> quad stuff if they add
>
> sorry, i do not understand your meaning.
>
> do you think the m25p80 can not support the quad read after this patch set?
>
>
>
>> 2) I didn't understand why the controller driver fsl-quadspi will be
>> in mtd becuase as it's (q)spi driver
>> may does flash or non-flash functionalities if ie, the case should be
>> part of drivers/spi/*
>
> Please read this thread, Mark though it should be spi nor driver:
>
> http://marc.info/?l=linux-arm-kernel&m=137782885415953&w=2
>
>> 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
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.

Now please tell me how your framework works in this case? how many
drivers do I need to right
and call traces.

-- 
Thanks,
Jagan.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux