Question regarding FlexSPI controller available on NXP boards

Patryk <[email protected]>
Newsgroups org.kernelnewbies.kernelnewbies
Message-ID <CA+DkFDbmszHGrUVCCN6PuN9tnAkBMPwX-Pm=NJu8LT1c7zgt=w@mail.gmail.com>
Hi,
I've got a question regarding FlexSPI controller available on e.g
imx8mm or ls1028/2160 boards.
To not waste your time here is tldr;
Does spi-nxp-fspi controller (and Linux driver) support simultaneous
read/write transactions?

More details here:
I have two boards, the first one is LS1028a, and the second one is
Hilsher netX90 and I need to connect these two over SPI. The only
available SPI controller I have on my board is FlexSPI. From what I've
found in the documentation by using LUT sequences I should be able to
adapt it to the protocol that is needed by netX90.
There is just one problem: netX immediately sends some status
information (1 status byte followed by 3 undefined bytes) once the
master starts clocking, which results in simultaneous transfer on both
MOSI and MISO lines.

Eg when I want to issue a read operation on netx, I send the following
byte stream:(1 byte cmd, 3 bytes addr, 1 byte length)

MOSI: 0x80 | 0x12 0x34 0x56 | 0x4

MISO: 0x11 | 0xXX 0xXX 0xXX | data[0]... data[3]

As you can see the status byte - 0x11 (followed by some undefined 3
bytes) is immediately sent over the MISO line. Then, data[0]...data[3]
is actual data that was requested to fetch.
I tried to use spi-mem framework that is supported by spi-nxp-fspi
controller driver, but it does not support handling simultaneous
transfer thus at the end of the SPI transaction I ended up with a rx
buffer consisting of data[0]...data[3] only.

Kindly asking for any advice. Unfortunately, there is no way to use a
traditional SPI controller in this case, as all of them are used for
other purposes.

BR
Patrick

_______________________________________________
Kernelnewbies mailing list
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.