OSDMP157C: DCMI overruns triggered by SPI5 transfers when DMA is enabled

Do you have readouts of those MDMA registers from a successful 25600-byte transfer on SPI5?

Here’s the next thing I’d try:

In your device tree node for SPI6, set the dmas property as follows:

dmas = <&mdma1 34 0x0 0x40008 0x0 0x0 0x0>,

<&mdma1 35 0x0 0x10040002 0x0 0x0 0x0>;

Compared to stm32mp151.dtsi, which has 0x40002 as the third parameter in the TX DMA, the value 0x10040002 should enable block transfer mode. If this doesn’t work (we might need to tweak more things for the block transfer to complete successfully), send the error/register dump from dmesg again. (Unfortunately I don’t have a similar SPI display laying around to actually test on.)

Full thought process, starting with what I think caused the overruns with your original SPI5 configuration:

– DCMI is always going to be using one of the standard DMA controllers, DMA1 or DMA2 (selected by the DMAMUX) [1].

– SPI5 will also be automatically assigned a stream by the DMAMUX driver in the same way [2]. Most likely, all eight streams of DMA1 are not yet occupied, and so both DCMI and SPI5 end up on the same DMA1 controller.

– DMA1/DMA2 only arbitrate between streams once a request is completely finished [3]. That is, DMA1 will wait until your 26Kbyte display frame is completed before possibly servicing the DCMI, even if the DCMI stream has a higher priority.

– Probably, the display frame transfer takes long enough over SPI5 that a DCMI frame is guaranteed to start before the display frame transfer is completed. Check whether this is true with whatever framerate you use for your image sensor.

– So then the DCMI FIFO is guaranteed to overflow anytime you transfer a display frame, regardless of priority.

So we either need SPI display frame transfers to be much faster, or we need to use a separate DMA controller. Incidentally, your SPI6 configuration achieves exactly that and uses MDMA instead [1]. (The separate DMA controller is what we need, not proximity to the ARM cores [4].)

MDMA breaks because TRGM[1:0] is left as 00 in CTCR (as if to configure a buffer transfer) but the data length is set in CBNDTR (for a block transfer). The TLEN (for buffer length) is left as the default one byte, which can’t be packed into a 16-bit write to the peripheral, so you get the BSE error. The MDMA driver seems to deal with the data length registers properly (you must use a block transfer above 128 bytes), but it doesn’t automatically switch to a block transfer in CTCR. In the device tree property above, I’m setting TRGM[1:0] in CTCR to 01 instead of 00. More debugging might be required after this, but you definitely need the MDMA to be in block transfer mode.

[1] per stm32mp151.dtsi.

[2] line 110 of stm32-dmamux.c.

[3] section 2.2.3 of ST AN4031. F7, H7, and MP1 use the same DMA IP as far as I know.

[4] The A7 cores are not involved during DMA transfers between memory and a peripheral.

Octavo, is there some sort of allow-list that the forum has for trusted users so that I could post links without being caught by the spam filter? 🙂

• This reply was modified 1 year, 4 months ago by Aedan Cullen. Reason: fixed missing zero in hex

<p id=”docs-internal-guid-70e29185-7fff-97b0-0d38-c39dbf26df72″ dir=”ltr”>Awesome, I’m glad you got it working. I think the reason you can’t directly set &dma2 in the device tree is that DMAMUX configuration is needed to route the request signal from DCMI to DMA2 within the SoC, and that remains unconfigured if the device tree only references the DMA controller directly. You could potentially try changing only the SPI TX DMA to &dma2 to see if that’ll still work since the CPU is starting the transfer – I didn’t yet look closely to see whether it should.
<p dir=”ltr”>In the stm32-dmamux.c driver, it definitely seems to be an oversight that there is no provision for manually choosing a controller. They just take the 16 total channels (eight DMA0 followed by eight DMA1) and assign them sequentially as you saw. I think ST may not have anticipated/tested DMA use for simultaneous video streams like this. The cleanest approach I can think of right now would be to improve the stm32-dmamux.c driver to add (optional) manual multiplexing control in the device tree.