RE: support DUAL and QUAD[patch v1]

["Gupta, Pekon" <pekon-l0cyMroinI0@public.gmane.org>]

> 
> > > Maybe it would make more sense to have a spi-rx-width and spi-tx-width
> > > than can be set to 1, 2, 4, etc. bits instead of a bunch of properties
> > > that are mutually exclusive?  Sooner or later someone is going to want
> > > 8 bits.
> 
> > Then it would not remain a serial interface (Serial Peripheral Interface),
> > rather it would be more of parallel memory like interface.
> > And you would not like to use SPI controller for it, instead you would use
> > On-chip General Purpose External Interface controllers (like GPMC)
> > because it gives you more options to tweak and configure.
> 
> It's still not beyoond the bounds of possibility, and of course some
> bright spark might decide to use 3 wires.  Unless it's expensive to do
> so in some way it seems better to keep the interface as generic as
> possible even if we've no expectation that some of the flexibility will
> be used.
> 
Ok.. Agreed,  I don't have any preference here between
"rx-width , tx-width" v/s "mode".
But please make sure that whichever implementation is chosen,
it should allow dynamic changing of channel-width.

Granularity should be based on following decisions:
(a) struct spi_message: if all transfers of same message follow same
 channel width. Example: All spi_messages from MTD layer would
use Qual-SPI only (both flash-commands and data).

(b) struct spi_transfer: if each transfer of same message need to be 
transferred at different width. 	Example: Command @ Single-SPI
 followed by Data @ Quad-SPI


with regards, pekon

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk