On 19 May 2016 at 12:19, Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote: > Can you try to apply this patch: > https://lkml.org/lkml/2016/5/10/315 I'd been wondering about that, but it seemed silly to me. EVAL (more typically known as EOI) is needed for cores that are hooked up to the pulse-outputs from EDMA, e.g. the C674x DSP on the DM814x, to avoid race conditions. Requiring it to be used to reset some invisible latch placed behind a level output would make absolutely no sense... ... and yet I've already seen similarly crazy constructions elsewhere on the SoC. :P Thanks for the pointer, I'll give it a spin. > It has been observed in the past the when UART DMA is enabled we will receive > DMA events even if there is nothing pending for DMA. If we did not ask eDMA to > recheck the status we could end up receiving a flood of interrupts and the > kernel will disable the interrupt line. That still implies however that a cc error is being generated for some reason. The patch merely fixes the stuck irq line. > I'll try to reproduce this on my side. It is just almost impossible to debug > since UART is using DMA so prints from DMA want to via UART -> DMA and we have > circular lock :o This is indeed a situation where the STM would come in very handy. Even if you don't have a trace receiver (I've been pondering the possibility to make one using PRU cores) you can log to the ETB (I think 32 KB?) and retrieve it from there after reboot. Fortunately this functionality is all very well documented... not :P Alternatives would be directly poking to another uart (just rudely disable its irqs and busy-wait for space in its tx fifo), or reserving a chunk of physical memory and writing messages there. Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
