Progress update on SPI questions:
I’ve found a lot of good information regarding SPI receive buffers and transmit buffers, and their “typical” sizes. (There are not really typical SPI buffer sizes, as these depend on amount of data to be transferred which varies a lot per device). The spi_bitbang sample in Zephyr RTOS 3.2.0 gives a wealth of information on typical buffer sizing. In interesting fashion as well, Zephyr’s SPI application programmers’ interface expects not a pointer to a single buffer for TX or RX, but a pointer to one or more such buffers. From the routine that’s linked just above and starts on line 49 of spi_bitbang main.c, it’s clear that the series or arrays of small TX and RX buffers can be set up prior to the call to spi_transceive(), and that proper set up of multiple such buffer pairs can create a multi-step SPI transaction in just a single call to Zephyr’s API.
Per main.c line 70 it looks like SPI write actions are realized by setting the RX buffer pointer to zero. When the transaction acts like an I2C “write read” transaction then both RX and TX buffers must be non-zero.
I have found that to read by one byte via Zephyr spi API, I must specify TX and RX buffers to have size of two elements, both of them. The first element of TX buffer goes from controller to peripheral. The second element of RX buffer receives the data which is sent from SPI peripheral to SPI controller. Some bytes in each buffer are seemingly not used, but both buffers must have equal length. They must mirror each other in size.
Though I cannot confirm it, it looks like the answer to my question about DMA set up is that having DMA controller enabled in SoC level device tree source, and DMA channel references made in an enabled SPI controller node is sufficient to set up DMA for hardware, as opposed to bit-banged, SPI controller use.
I’d been spinning my wheels for a while, for not looking in the right place sooner. But I think we can mark my questions in this post answered.