OSDMP157C: DCMI overruns triggered by SPI5 transfers when DMA is enabled
- This topic has 6 replies, 3 voices, and was last updated 1 year, 4 months ago by
.
Here’s the next thing I’d try:
In your device tree node for
SPI6, set thedmasproperty 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:
–
DCMIis always going to be using one of the standard DMA controllers,DMA1orDMA2(selected by theDMAMUX) [1].–
SPI5will also be automatically assigned a stream by theDMAMUXdriver in the same way [2]. Most likely, all eight streams ofDMA1are not yet occupied, and so bothDCMIandSPI5end up on the sameDMA1controller.–
DMA1/DMA2only arbitrate between streams once a request is completely finished [3]. That is,DMA1will wait until your 26Kbyte display frame is completed before possibly servicing theDCMI, even if theDCMIstream has a higher priority.– Probably, the display frame transfer takes long enough over
SPI5that aDCMIframe 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
DCMIFIFO 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? 🙂
- You must be logged in to reply to this topic.