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

On Sun, Jan 19, 2014 at 7:58 AM, Huang Shijie [off-list ref] wrote:

? 2014?01?17? 16:39, Jagan Teki ??:

quoted

On Fri, Jan 17, 2014 at 12:24 PM, Huang Shijie [off-list ref]
wrote:

quoted

On Fri, Jan 17, 2014 at 12:36:08PM +0530, Jagan Teki wrote:

quoted

quoted

quoted

My basic question is like I have a qspi spi controller in my SOC and I
designed two boards B1 and B2

okay.

quoted

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" :)

I'm still not convinced here, sorry!
Let me explain more with example, Just take your (q)spi controller as an example
B_FSL1 designed with - serial flash
B_FSL2 designed with - touch screen

With this design If we follow current we just need one controller
driver (drivers/spi/spi-fsl.c)
to serve touch screen and serial flash from upper layers.

MTD core                Input core
-------------           -------------------------------
m25p80.c             spi  touchscreen driver  (drivers/input/touchscreen)
----------------------------------------------------
                          SPI core
----------------------------------------------------
      controller driver (drivers/spi/spi-fsl.)
----------------------------------------------------

But with your new SPI-NOR

MTD core
------------
SPI-NOR              Input core
-----------           ------------------
fsl-quadspi.c     spi  touchscreen driver  (drivers/input/touchscreen)
----------------      ------------------------------
                         SPI Core
                         -----------------------------
                         controller driver (drivers/spi/spi-fsl.c)
                         -----------------------------------------

Here see we have two separate drivers for the same controller as it offers two
functionalities. and also it never talk to Linux SPI subsystem which is not a
good for me as intern hw is SPI-based it must talk to subsystem to make use of
Linux SPI API's.

And also you mentioned SPI-NOR controller is not a SPI controller what does that
means because it's a NOR flash which is of SPI protocol based.

I understand that your framework doing good things in matured manner, but
seems like it's confuse to me to follow common standards - Just my
opinion, may be I'm incorrect.

One more thing question - I have 1-wire spi controller which I was
used for flash in
one board and keyboard in another board, so if I follow your framework
I need to write
a driver in drivers/mtd/spi-nor/foo-spi.c and one more in
drivers/spi/spi-foo.c - correct?

This framework does nSPot 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.

quoted

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,
Jagan.