Jagan,
> On 25 Feb 2017, at 09:43, Jagan Teki <ja...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
