RTEMS | dev/serial/zynq: Improve baud calculation and simplify code (!199)

[Chris Johns (@chris)]

Chris Johns started a new discussion on bsps/shared/dev/serial/zynq-uart-polled.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/199#note_111947

 >      | ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_NONE)
 >      | ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_8)
 >      | mode_clks;
 > -
 > -  while (zynq_uart_read_char_polled(regs) >= 0) {
 > -    /* Drop */
 > -  }
 > -
 > -  zynq_uart_reset_tx_flush(regs);

The commit comment is correct. It should be noted the flush sending the data worked around an issue or bug in the Versal UART related to how our termios works. With interrupts active our code assumes an TX interrupt can be triggered by a single termios character write to a TX holding or shift register. The Versal UART with a FIFO mod to the ARM cell design required half the programmed FIFO to be filled to generate the first TX interrupt after which things worked normally. I reviewed the Linux driver and our driver and could not see any functional differences other than Linux sends a 10+ character string as its first boot message. I am fine with the send of the `\r` being removed from the TX flush but the commit comment and the change do not line up.

We should wait for all TX data to be send before we touch the UART hardware and this means the TX shift register being empty. A deep FIFO may have data from the bootloader a user may be requited to see. Is there a TX flush before the UART hardware is touched?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/199#note_111947
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240911/91c82a84/attachment-0001.htm>