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

[Huang Shijie <b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org>]

On Sun, Jan 19, 2014 at 03:39:34PM +0530, Jagan Teki wrote:
> > 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)
>                          -----------------------------------------
> 
There is no relationship with the fsl-quadspi.c. 

It should be like this:
 MTD core
 ------------
 SPI-NOR  framework                       Input core
 -----------                              ------------------
 m25p80.c                                 spi  touchscreen driver  (drivers/input/touchscreen)
 ----------------                         ------------------------------
 SPI Core                                 SPI Core
 -----------------------                  -----------------------------
 drivers/spi/spi-fsl.c                    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.

The SPI controller (or spi bus controller) only handles the _byte_ streams;
while the spi-nor controller, such as fsl-quadspi.c, can has to __known__
the exact SPI NOR command to find the proper LUT.

Please read the thread i ever posted in the previous email.

> 
> 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?

Please read the device tree node of your controller, find the code like

...................................................
	flash: m25p80@0 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "st,m25p32";
		spi-max-frequency = <20000000>;
		reg = <0>;
	};
...................................................

if you call the m25p80,  you do not need to change anything. 

thanks
Huang Shijie

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html