AM5718: Multiple QSPI flash

Hi Nomo,

here is what I found out:

Nomo said:

1.Can we use multiple QSPI-Flash for the QSPI interface by the use of CTRL_CORE_CONTROL_IO_2.QSPI_MEMMAPPED_CS?
  We want to use two 64M Byte QSPI-Flash instead of using one 128M Byte QSPI-Flash.
  And we want to know the feasibility of that a QSPI-Flash is connected to CS0 and another Flash is connected to CS1.

Yes you can connect up to 4 QSPI devices to the QSPI hardware module of the device. The 'drivers/spi/spi-ti-qspi.c' Linux driver uses and initializes the QSPI_MEMMAPPED_CS bit field as part of accessing each SPI slave memory device. Note that there is a recent commit on the TI Linux 4.19 Git tree which is part of the Processor SDK v06.00.00.07 you are using:

http://git.ti.com/gitweb/?p=processor-sdk/processor-sdk-linux.git;a=commitdiff;h=e51c5ec99597005400184fcd165d71c875bba367;hp=0d98ecb141a65ccea0ddef82b5cf3a1d5a777695

The commit message suggests that there was an issue with accessing multiple SPI slaves in memory-mapped mode that is fixed with this commit.

Nomo said:

2.Is this switching of CS supported by the Linux driver?
  The SDK is PROCESSOR-SDK-LINUX-RT-AM57X and the version is v06_00_00_07.

While I have not tried it myself due to lack of appropriate hardware but reviewing the driver code shows that up to 4 slave devices are supported. There are examples of other boards in the DTS folder that attach multiple SPI slaves to the QSPI module, so you could model after that, see here as an example to show how to specify the chip-select node for each SPI slave: http://git.ti.com/gitweb/?p=processor-sdk/processor-sdk-linux.git;a=blob;f=arch/arm/boot/dts/am57xx-cl-som-am57x.dts;h=203266f884807e3a2cced5c35c56e6d92fc69bf9;hb=refs/heads/processor-sdk-linux-4.19.y#l490

Nomo said:

3.If the answer of 1 and 2 is yes, can we switch the CS (accessing to each QSPI-Flash) dynamically?

The driver should dynamically update the the memory-mapping depending on which device / CS you are using. The function ti_qspi_exec_mem_op() that is used during memory-mapped SPI transfers is making a call to another function named ti_qspi_enable_memory_map() that configures QSPI_MEMMAPPED_CS depending on the SPI slave getting accessed, so it all should work. In case it doesn't work, the call to ti_qspi_enable_memory_map() may need to be made unconditionally, meaning not dependent on 'if (!qspi->mmap_enabled)' so that it always gets executed to ensure the proper CS-specific remapping.

http://git.ti.com/gitweb/?p=processor-sdk/processor-sdk-linux.git;a=blob;f=drivers/spi/spi-ti-qspi.c;h=b9fb6493cd6b9f0fe59c7e27ad98208227473061;hb=5f8c1c6121da785bbe7ecc5896877a2537b5d6eb#l553

Regards, Andreas

Nomo-san,

Andreas Dannenberg63 said:

The driver should dynamically update the the memory-mapping depending on which device / CS you are using. The function ti_qspi_exec_mem_op() that is used during memory-mapped SPI transfers is making a call to another function named ti_qspi_enable_memory_map() that configures QSPI_MEMMAPPED_CS depending on the SPI slave getting accessed, so it all should work. In case it doesn't work, the call to ti_qspi_enable_memory_map() may need to be made unconditionally, meaning not dependent on 'if (!qspi->mmap_enabled)' so that it always gets executed to ensure the proper CS-specific remapping.

I talked to our Linux driver developer that owns this driver, and he thinks the potential issue I identified may indeed be a bug. He is going to look into this more closely in a few days and to see if this needs to be fixed. If that's the case I'll report back here. Until then please keep my above recommendation in mind should you see any issues.

Regards, Andreas