On 05/19/16 14:02, Matthijs van Duin wrote: > 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 know... But if the dma_ccerr_handler is called and there is nothing in the error status registers (EMR/EMRH, QEMR or CCERR) there is nothing the handler can do since according to the error registers there is nothing need to be done. >> 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 > -- Péter -- 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
