On Sat, Jan 12, 2013 at 7:50 AM, Chanho Min <chanho.min@xxxxxxx> wrote: > We tested as follows: > We set baud rate to 3Mbps and transfer 5000 bytes via /dev/tty at > a time. Then 4096 bytes is received by DMA irq. But, There is no way > to get remaining 904 bytes, unless another 3192 bytes are coming, OK clearly cut phenomena: IRQs seem to appear from the PL080 TC (transfer complete) IRQ only, not from any of the PL011 IRQs. So there will be zero IRQs from the uart in /proc/interrupts but a few of them from the PL080, correct? >>- What DMA controller are you using with the >> PL011? > > PL080. > We don't add any customized configuration from the mainline. OK sorry I was thinking of the old times when we has .cctl configured from the platform. >> - If they cannot be software-configured, how are >> they then configured in hardware? Burst-only? >> Burst single > > As far as I know, single request is not disabled at PL080. > Could you explain what single request has to do with this? At some point we reasoned that we may actually be saved by the reverse phenomena - if single request is *NOT* connected, there will very often be some characters in the FIFO, and that's enough to trigger the RTIM IRQ, and we get a nice flow. So maybe the platforms that actually work, work because they have bursts only. But that would pose a problem when an even burst of characters arrive. Say 16 characters, this will be transferred in two bursts and leave the FIFO empty, but no DMA TC IRQ since the buffer is not full, and we'd get your phenomena. But I could never reproduce the latter theoretical problem, so I think the hardware actually has a fix for this, around the burst signal logic. But it may very well be that the single request can not be enabled for the PL011 for it to work properly. You may not be able to turn this off, and in that case this kind of code is the only way forward indeed. Yours, Linus Walleij -- 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
