On 21 March 2017 at 18:11, Jiahuan Zhang <[email protected]> wrote:
> What do you mean "RXFE will be cleared"?
> Here RXFE is
> #define PL011_RXFE 0x10
I mean that as soon as 1 byte of data is ready to read the
RXFE bit will be cleared in the FR register. So you need:
/* probably you want to actually detect EOF somehow but let's
* just read 16 bytes
*/
for (i = 0; i < 16; i++) {
while (*UART_FR & PL011_RXFE) {
/* loop until data available */
}
/* now read 1 byte, that's all we can be certain is there */
data[i] = *UART_DR;
/* ...and then go back and check RXFE again */
}
>> Are you saying that QEMU is looping round indefinitely calling
>> pl011_can_receive() and never running the guest at all?
>
>
> Yes, exactly when fifo is full, s->count = 16. pl011_can_recieve keeps
> returning 0.
> The guest program is blocked.
Right, but if can_receive returns 0, then QEMU should decide
"OK, can't do anything here" and run the guest.
> I am using a windows named pipe to get the data from a window
> host program, which uses ReadFile () in char_win.c
OK, bugs in the windows-specific char backend would be
unsurprising.
I'm not entirely sure how the chardev layer works, but
at the pl011 end if we return 0 from our can_receive
function then the chardev layer should decide it has
nothing to do until the pl011 later calls
qemu_chr_fe_accept_input(), I think.
I've cc'd Paolo and Marc-André Lureau as the chardev
maintainers.
thanks
-- PMM
