[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