support DUAL and QUAD[patch v1]

[Gupta, Pekon]

> 
> Hello Pekon,
> 
> Gupta, Pekon wrote on 2013-07-16:
> > >
> > > Hi, Gupta
> > >
> > >
> > > > [Pekon]: Instead of adding new fields you can use existing 'mode' field
> to
> > > > pass on the platform specific configurations. And if 'u8 mode' does not
> > > > suffice you can increase it to 'u32'.
> > > > #define QSPI_MODE       1 << 5; // just check which bit-fields are un-
> used
> > > > spi_board_info->mode |= QSPI_MODE;
> > > >
> > >
> > > well, can dual and quad be regarded as a spi mode? if so, your comment
> > > seems
> > > to be right.
> >
> > Yes, Quad and Dual modes should be regarded as extension of SPI
> protocol.
> > - They follow the same basic principle of synchronous data transfer. Right ?
> > - These modes are not adding any extra side-band | In-band signaling or
> > controls to modify the protocol. They are just increasing the width of
> >  data-channel for better throughput.
> >
> > with regards, pekon
> >
> 
> In general, yes. But I think, for the interface we have to take care of more
> details.
> 
> For example, what happens in the following situation:
> We have a spi-controller, which supports the QSPI mode, and a spi-flash,
> which fulfils
> the requirements, but the board has not connected all signals?
> 
[Pekon]: So, actual implementation should set QSPI_MODE based on both
(1) device capabilities (detected in probe)
(2) board-DT properties (this would take care of your other constrains)

> And the interface for the slave-driver (like m25p80) should allow to specify
> the transfer mode
> for each spi_message.
> This will be necessary, because it depends on the flash and mode, how each
> phase of "cmd",
> "address", and "data" will be transferred.
> 
[Pekon]: Are you saying that same controller can send interleaved 
Quad-SPI and Single-SPI spi_messages to same device (here flash device)?

Is it due to flash-device constrain that it accepts some flash-commands 
(like erase, etc) only on Single-wire-SPI, whereas  data transfers can be 
Performed on Quad-SPI mode ?
In such case you need to add 'mode' field in struct spi_message, so that
this information moves along with the spi_message in queue. And then
when that message reaches spi_pump_message() and 
transfer_one_message() is called, then you can do needful configs.

However, I still don't think you need to control 'QSPI_MODE' at granularity
of spi_transfer level, because m25p80 flash-driver use spi_write() API to
pass data to SPI driver, which internally creates a spi_message in each call.

Following best explains use of spi_message in /include/linux/spi.h
---------------------------------------------------
* A @spi_message is used to execute an atomic sequence of data transfers,
 * each represented by a struct spi_transfer.  The sequence is "atomic"
 * in the sense that no other spi_message may use that SPI bus until that
 * sequence completes.  On some systems, many such sequences can execute as
 * as single programmed DMA transfer.  On all systems, these messages are
 * queued, and might complete after transactions to other devices.  Messages
 * sent to a given spi_device are alway executed in FIFO order.
---------------------------------------------------


> I don't know, if it is only me, but I would like to see some more abstract
> description for all
> these scenarios, before the details of an interface really could be discussed
> and decided.
> 
Agree.. Does above matches your requirement ?

 
with regards, pekon

> Best Regards,
> Thomas