Re: Uartlite - ulite_transmit

[Peter Korsgaard <jacmet@sunsite.dk>]

>>>>> "Michal" == Michal Simek <monstr@monstr.eu> writes:

Hi,

 Michal> I looked at that loop and I think that we should reread actual
 Michal> status before ulite_transmit because status reg can be changed
 Michal> when ulite_receive is executed. What do you think? (BTW: status
 Michal> reading can be moved directly to ulite_receive/transmit
 Michal> functions)

 Michal>     do {
 Michal>         int stat = ioread32be(port->membase + ULITE_STATUS);
 Michal>         busy  = ulite_receive(port, stat);
 Michal>         stat = ioread32be(port->membase + ULITE_STATUS); // check
 Michal> status again
 Michal>         busy |= ulite_transmit(port, stat);
 Michal>         n++;
 Michal>     } while (busy);

It shouldn't really matter - ulite_transmit() only looks at TXFULL, and
in the unlikely case where it was full but 1 character got transmitted
during ulite_receive, we will catch it during the 2nd iteration of the
loop (as busy will be true).

The logic was afaik more-or-less directly copied from 8250.c

 Michal> 1. Before fault happen:
 Michal> ISR is called, status is 0x18 (interrupt enabled, tx fifo full) just
 Michal> to ulite_transmit and detect TXFULL and return to ISR. Head and tail
 Michal> are correct
 Michal> 2. Broken part
 Michal> ISR is called, status is 0x14 (interrupt enabled, tx fifo empty), jump
 Michal> to ulite_transmit. Here I am printing (head and tail values are
 Michal> zero). Xmit buffer address is the same. Then uart_circ_empty(xmit)
 Michal> detects that head and tail are the same which means nothing to print.

 Michal> My question: Is there any part of the code which can change xmit head
 Michal> and tail values?

Yes, ulite_transmit does (for tail). head is only changed by the serial core.

 Michal> BTW: Getty is providing that login prompt. Could it be an issue with getty?

Maybe. Or the fact that it calls set_termios or similar. Are you unable
to reproduce the problem with other programs?

-- 
Bye, Peter Korsgaard