On 09/15/16 17:32, Sebastian Andrzej Siewior wrote: > 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). According to atom-z36xxx-z37xxx-datasheet-vol-1.pdf I have found on the Intel: "When the number of entries in the Receive FIFO is less than its trigger level, and no additional data is received, the remaining bytes are called Trailing bytes. These are DMAed out by the DMA as it has visibility into the FIFO Occupancy register." None of the TI DMA engines are aware of the IP's internal registers so this can not be done. > 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. I did not really checked the OMAP UART DMA support patches from the IP point of view, but now that it is back again - for some reason it caused all sort of issues so far in many levels - I have taken a peek into the driver and the datasheets. The question it brought up for me is: - Why the RX FIFO threshold set to 48? 42 would be better? - Why TX FIFO threshold is set to 1? Why not 48 (or 42)? - according to the documentation, the UART_IER register's bits are different in different modes, in DMA mode the UART_IER_MSI, UART_IER_RLSI, UART_IER_RDI, etc are not applicable when the FIFO is enabled. If I read it right. I got the impression from the documentation that it is best to use RX FIFO threshold 1 so we receive all bytes into the memory one-by-one. Or I think we could use higher threshold and we need to respond to drain the FIFO with CPU by responding to EOF interrupt (enabled by bit 7 in IER register when the FIFO is enabled) >> 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). Yep, if you set 48 as RX threshold then the DMA must read out 48 words in response to a DMA request. DMA request will be not asserted until there are 48 words in the FIFO, so yes, if we receive less then 48 characters from start till end of reception we will have no DMA activity as there were no DMA request coming from UART to the DMA. >> 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 have hard time to follow this... The IP's threshold and the DMA burst size must be configured in sync. If you say in the IP to generate the DMA request when the FIFO have 48 bytes, then you need to program the DMA to read 48 bytes. If you set the UART FIFO threshold to 16 bytes, then you need to configure the DMA burst size to 16 bytes as well: "This request (RX DMA request) is deasserted when the number of bytes defined by the threshold level is read by the device DMA controllers." > I agree that this is how it should work and I assume > that the Intel HW does this. But OMAP does not. The Intel DMA knows the UART FIFO level. The TI DMAs are generic DMAs and have no access to IP registers. > 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. Hrm, my bet would be that Enabled FIFO + 1 byte threshold should be the safest and working mode for UART. > 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. I'm not sure if I get this right, but are you saying that if you program UART first, enable UART RX then enable the DMA it will not work at all? That is really strange indeed. One thing might be that you quickly overrun in UART and that causes things to fail? But as I have said: I'm not an expert on the UART side, I don't even know how to properly test the UART DMA,a nd to be honest I do keep it disabled most of the time as it interfere with my DMA driver work. I was planning to propose to have a way to disable the UART DMA for console UARTs as there is no real point of having DMA for that. -- 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
