On 2016-09-15 16:58:45 [+0300], Peter Ujfalusi wrote: > > This is why the OMAP's DMA code programs the DMA transfer upfront. > > Not really. The reason we tend to set up the DMA first (speaking of audio, bu > applies to other peripherals imho): > at the start of TX the FIFO is empty, if we release the TX in the peripheral > it is going to underrun as there is no data in the FIFO. SO we start first the > DMA, enable the DMA requests in the IP and then release the TX. This way the > FIFO will contain valid data. > On the RX side the issue is if we do not have FIFO. If we enable the RX but > the DMA has not been started we will have overflow in the peripherals as the > next incoming data will overwrite the previous one - no one is reading the > data out yet. So we start the DMA first, which will wait for the request to > read the data out. I am not saying starting RX DMA first wrong or so. It does make sense. However on the OMAP it is a must to get things working. On the Intel HW (which contributed the DMA support) it might work, too. But nobody seems to have tested it and verified it. As I said: OMAPs says I want X bytes and completes once X bytes arrived in the FIFO. From the code it seems Intel says we want 4KiB bytes and the DMA engine and DMA completes at the "TIMEOUT" level with less than 4KiB bytes (or at "done" point with 4KiB of data). So if the OMAP's RX-DMA logic works for others why not move it generic. > But if you have FIFO on the RX, then the DMA can be started after the UART > started the reception, as long as it is not delayed too long that we will have > overrrun in the FIFO. Yes, you don't want to overrun the FIFO, understood. *But* Throw just 48 bytes into the FIFO, program the RX transfer and wait. You will get a few RX interrupts, followed by an timeout interrupt. The DMA engine will never start working. I *think* the UART is counting wrong and never signals the DMA engine to start doing its work. > So if we have 1 byte in FIFO when we start the DMA, then > the DMA will read that out, then the next, then the next, until it received > 48bytes, No, it will not. OMAP because as I think because it counts wrong. In general it won't because it transfers no less than burst size (and it is currently set to 48 for OMAP). > if that is what it has been configured. But AFAIK we use bursts from > UART, so we configure that the FIFO should have 40(?) bytes and only then the > DMA request should be asserted. DMA will read the 40(?) bytes out, so again it > does not matter if we had 1 byte in the FIFO when the DMA started. In general: burst size 48, program transfer with 16 bytes in the FIFO. The transfer should start (DMA asserted by the UART) once the remaining 32 bytes have arrived. I agree that this is how it should work and I assume that the Intel HW does this. But OMAP does not. Before having the 48 bytes as burst I had 1 byte. At this point the DMA engine transferred one byte at a time but something else was not perfect so I went for 48. Nobody at TI could answer my question why the RX-DMA is not triggered by the UART if the RX transfer was not programmed prio the reception. I received even bare metal code where, according to the code, the RX transfer was programmed _after_ the first byte has been received. I tried to run this in Linux (as I was not able to run this bare metal) and I could not confirm that this works. Sebastian -- 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
