Hard lock up on Raspberry pi 3 when RTDM interrupt from SPI peripheral or from DMA is invoked
rpm at xenomai.org
Mon Aug 5 21:19:34 CEST 2019
On 8/5/19 9:11 PM, Philippe Gerum via Xenomai wrote:
> On 8/5/19 5:51 PM, Nitin Kulkarni via Xenomai wrote:
>> I am trying to request DMA interrupts in real-time domain. When I request
>> the irq with rtdm_irq_request(), the irq is successfully registered but at
>> the first interrupt the system goes into a hard locked state.
>> I tried the RTDM SPI driver for RPI (spi-bcm2835.c) provided in the Xenomai
>> even that makes the system lock up. I have enabled IPIPE_DEBUG and tried to
>> see if I get any useful trace but no luck.
>> GPIO interupts working:
>> I thought to check if the GPIO interrupts also have same issue but
>> fortunately the GPIO interrupts work fine.
>> I suspect (Correct me if I am wrong) it has got to do with the nested irq
>> controllers in bcm2836 and bcm2837 which makes it different from bcm2835.
>> The GPIO irqs are not routed through these interrupt controllers I think
>> and thus the i-pipe patch works fine for bcm2836 as well.
>> It would be great if someone can throw some light onto this problem. Has
>> anyone tried to use real-time SPI or DMA on a RPI 3 ? Or if someone can
>> show some direction in how to fix the irq chips driver it would be very
> There are several reasons this cannot work, this is not an irqchip
> issue. Basically, the DMA chip is controlled by the bcm2835-dma.c
> driver, which abides by the generic dmaengine kernel framework. For this
> to work, you would have at least to reserve the DMA channels involved in
> SPI xfers, configure them, and manage the transactions the way the
> bcm2835-dma driver and the framework do for regular operations,
> including proper acknowledge of the DMA events for real-time requests
> directly from primary mode, or propagation of DMA completion/error
> events to regular issuers running in secondary mode. It should also
> include a way to start transfers from primary mode (aka issue_pending
> request in the dmaengine API).
> The other - better way - would be to teach dmaengine about the existence
> of a co-kernel context, so that it can handle requests from Cobalt
> threads running in primary mode, along with requests issued from regular
> kernel context.
dmaengine _and_ bcm2835-dma would have to be updated.
More information about the Xenomai