On 2016-09-20 12:57:54 [+0300], Peter Ujfalusi wrote: > 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? The FIFO depth is 64. So I went for a transfer after 3/4 of the FIFO is full. I don't know how 42 is computed. > - Why TX FIFO threshold is set to 1? Why not 48 (or 42)? So you can DMA an arbitrarily number of bytes. Otherwise you would be forced to program a multiple of 48 (or 42) and push the remaining bytes manually. > - 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 would have to look those up. > 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) How is threshold 1 applicable? Wouldn't you get an interrupt after each byte? > >> 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. correct. > 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 intended to follow this :) > > 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? - program the UART (baud rate, etc) - send from the remote side 48 bytes (just 48). The data will stay in UART's FIFO - UART will generate RX interrupt will - program DMA engine to transfer 48 bytes (at this point the UART has probably 4 byte in its FIFO while the remaining data is still dropping in). - UART will continue generate RX interrupts - UART will generate a TIMEOUT interrupt the mode that is currently used: - program the UART (baud rate, etc) - program DMA engine to transfer 48 bytes. - send from the remote side 48 bytes (just 48) - DMA engine will transfer 48 bytes once 48 bytes are UART's FIFO and generate a transfer-complete interrupts - UART will generate an interrupt. The interrupt-status register will read "nothing" because it was a RX interrupt which was cleared by the DMA engine (usually you won't notice this but at 2Mbaud you will likely see "nobody cared" and the core will disable the UART interrupt). > That is really strange indeed. One thing might be that you quickly overrun in > UART and that causes things to fail? no overrun. I used [0] so send stuff in simplex / duplex mode or just a specific amount of data. > 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. By the time I worked on it I had it enabled on my am335x and dra7. I had the test tool [0] the check for large transfers. For console uarts it makes no sense since you usually get like 2 characters a second. On RX side what happens here is _usually_ a timeout interrupt and the FIFO is drained in PIO mode. This is something you *don't* notice. On the TX side you get larger transfers for instance during "dmesg" output. [0] https://git.breakpoint.cc/cgit/bigeasy/serialcheck.git/ 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
