Re: [RFC] Switching 8250_omap to use 8250_dma RX and TX flow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux