[U-Boot] [PATCH v1] spi: sunxi_spi: Add DM SPI driver for A31/A80/A64

[Dr. Philipp Tomsich]

Jagan,

> On 25 Feb 2017, at 09:43, Jagan Teki <jagan at openedev.com> wrote:
> 
>> +/* The SPI flash opcode for a FAST READ DUAL OUTPUT operation. */
>> +#define CMD_READ_DUAL_OUTPUT_FAST 0x3b
> 
> Flash(slave) specific opcodes shouldn't use it on spi driver, try to
> implement the spi in generic way instead of making to handle only
> specific slave.

I do agree, but there’s unfortunately a reason why this needs to be
in a SPI driver in U-Boot at this time: the SPI-NOR flash layer does
not correctly understand how a “FAST READ DUAL OUTPUT” cmd
is to be sent:
	— the dual-IO fast-read needs to transmit the (a) cmd and
	(b) 4-byte address as single-IO, then switch to Hi-Z while
	sending a dummy-byte and then receive in dual-IO
	— the SPI-NOR flash layer only sets the SPI_RX_DUAL mode
	flag for the all exchanges and issues two separate spi_xfer
	calls for the write and read phases (with the same mode).

I had a prototype implementation that added an additional spi_xfer
interface that allowed to specify a complete transaction (i.e. single-io,
dummy and dual-io phases), but switching the SPI-NOR layer to this
caused significant disruption there (it started to look like a rewrite, as
the probed READ_CMD couldn’t be described as a single-byte any
longer, but needed info on the transmission modes for CMD, ADDR,
dummy and data-in)… so it looks like a longer-term project.

Please note that
	drivers/spi/ich.c
	drivers/spi/fsl_qspi.c
use similar mechanisms to detect flash transactions and handle them
in a special mode.

Note that with the current implementation, this only code-path only 
has an effect if a dual-IO flash is configured as a slave (we even
check that the slave device is a flash-device according tot he DM).

Regards,
Philipp.