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

Huang Shijie shijie8 at gmail.com
Sat Jan 18 21:28:52 EST 2014


于 2014年01月17日 16:39, Jagan Teki 写道:
> On Fri, Jan 17, 2014 at 12:24 PM, Huang Shijie <b32955 at freescale.com> wrote:
>> On Fri, Jan 17, 2014 at 12:36:08PM +0530, Jagan Teki wrote:
>>>>> 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?
>> Take drivers/spi/spi-imx.c for example, if you connect a NOR to it, you only
>> need to add a NOR device node in the device tree. In the probe, it will call
>> the m25p80.c to probe the NOR device.
>>
>> But if we connect other device to it. you should set another device node for it.
>>
>> I am not sure if your controller driver can works as the spi-imx.c
> My question here was - this new framework suggest to write a two
> different controller
> drivers one is for non spi-nor and spi-nor models? do you agree that?


If your controller can either connects to a NOR, or can connects to 
other devices, it means your controller is a _BUS_.
You just need to write the bus driver for your controller, such as the 
spi-imx.c and drivers/bus/imx-weim.c do.

Since you have connect a device to your controller. you also need to 
write a driver for your device, such as the m25p80.c is
for your spi nor device.

Just think about that how do you code your driver for SPI NOR _without_ 
this framework:
do your driver need to call the m25p80.c? if you do call the m25p80.c, 
you actually write your so-called "two drivers" :)


This framework does not change any logic for the current kernel, except 
adding a layer. With the new layer, we can code the
driver for the controllers which is a SPI-NOR controller, not a SPI bus 
controller.


>
> And also one important note from your design was spi-nor mode is
> completely bypassing
> Linux spi core is that the good idea?
>
yes. I think it's a good idea.

As Mark even pointed, the freescale's Quadspi controller is not a SPI 
controller, it is a SPI-NOR controller, it does _not_ need the
LINUX SPI core.


thanks
Huang Shijie



More information about the linux-arm-kernel mailing list