On Sun, Jan 19, 2014 at 7:58 AM, Huang Shijie <shijie8@xxxxxxxxx> wrote:
>
> 于 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" :)
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.
>
>
>
>>
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
