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]

 





于 2014年01月17日 16:39, Jagan Teki 写道:
On Fri, Jan 17, 2014 at 12:24 PM, Huang Shijie <b32955@xxxxxxxxxxxxx> 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
--
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