On Thu, 2016-02-25 at 14:20 +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 25, 2016 at 02:02:45PM +0000, Shevchenko, Andriy wrote:
> > Recently I've met an issue which, I guess, requires architectural
> > changes in virt-chan API.
>
> You are mistaken. :)
Might be.
>
> > HSU DMA Documentation states in particular "
> > If the UART receives data that does not reach the size of the
> > minimum
> > bus transfer size, than this data remains in the buffer and is
> > never
> > delivered to the memory by the DMA.
> > In order to resolve such potential problem, the UART generates a
> > timeout interrupt to the DMA. This interrupt is not dependent on
> > the
> > timeout enable bit in the UART but is always enabled.
> > Once the DMA receives such an interrupts, it will start emptying
> > the
> > FIFO and assert its own timeout interrupt to the CPU."
>
> I'm not sure about the terminology here: "UART generates a timeout
> interrupt to the DMA" ? Don't interrupts go to the CPU? That's what
> other UARTs do.
Let's consider simple transfer of 4696 bytes with internal loopback
...
R 29.927704 0xff010404 0x00000004 <- IRQ from DMA
R 29.927714 0xff010580 0x000f0001 <- Descriptor done
R 29.927729 IIR 0xc1 <- dup for UART!
R 29.927912 0xff010404 0x00000008
R 29.927925 0xff0105c0 0x000f0001
R 29.927944 IIR 0xc1
<- start last piece of transfer
W 29.928154 0xff0105c4 0x00000000
W 29.928165 0xff0105c8 0x00000000
W 29.928172 0xff0105d0 0x00000040
W 29.928179 0xff0105d4 0x00000000
W 29.928187 0xff0105e0 0x39be9000
W 29.928195 0xff0105e4 0x00001000 <- expect 4KiB
W 29.928202 0xff0105c8 0x01818101
W 29.928209 0xff0105c4 0x00000003
W 29.928620 0xff010584 0x00000000
W 29.928633 0xff010588 0x00000000
W 29.928640 0xff010590 0x00000040
W 29.928647 0xff010594 0x00000000
W 29.928655 0xff0105a0 0x39412000
W 29.928663 0xff0105a4 0x00000258 <- sent only 600 bytes
W 29.928671 0xff010588 0x01818101
W 29.928678 0xff010584 0x00000001
R 29.933346 0xff010404 0x00000004
R 29.933361 0xff010580 0x000f0001
R 29.933389 IIR 0xc1
R 29.933944 0xff010404 0x00000008 <- DMA IRQ
R 29.933959 0xff0105c0 0x000e0100 <- descriptor timeout
R 29.933992 IIR 0xc1 <- dup!
<- poll timeout in user space since we didn't get last part of data.
R 40.738944 MSR 0xb0
So, interesting combination. But looks like we get a shadow interrupt
from UART with NO_INT bit set.
>
> > Our current DMA <-> UART work flow relies on UART Timeout
> > Interrupt,
> > which is not happen in this case.
>
> That sounds like the UART is buggy.
Please, take a look at the above. Are you still keep this after?
>
> > What DMA Engine API provides us? The callback function and
> > possibility
> > to call a _tx_status() from it. During completion tasklet the flow
> > looks like this:
> > 1. Split completed descriptor to local list.
> > 2. Get callback functions for first descriptor in the list.
> > 3. Free the descriptor.
> > 4. Call callback. <<< descriptor related information is gone
> > already!
>
> If the completion function is called, then the DMA operation has
> completed, which means the full amount of requested data has been
> tranferred.
Okay, what about specific DMA timeout callback then?
>
> The way other UARTs handle this is that when the CPU receives the
> UART
> RX timeout interrupt, they pause the RX DMA, and ask for its status.
> The status callback tells you the DMA residue, which is the number of
> bytes remaining to be transferred. From that, you can work out the
> number of bytes that have already been transferred, and if you need
> to,
> read the remaining untransferred bytes from the UART, passing them
> all
> up to the higher TTY layers.
Yes, this is how I see in current code and my logic about the same, but
in hardware we have something slightly different.
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
Intel Finland Oy
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
��.n��������+%������w��{.n�����{��ǫ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
