On 27/03/2019 20:26, Chris Johns wrote:
On 28/3/19 5:28 am, Joel Sherrill wrote:
On Wed, Mar 27, 2019 at 1:10 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>>
wrote:
On 26/03/2019 15:17, Lou Woods wrote:
> From: Lou Woods <lou.wo...@oarcorp.com>
>
> ---
> bsps/arm/xilinx-zynq/console/zynq-uart.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/bsps/arm/xilinx-zynq/console/zynq-uart.c
b/bsps/arm/xilinx-zynq/console/zynq-uart.c
> index fa91f3f..9c21f6f 100644
> --- a/bsps/arm/xilinx-zynq/console/zynq-uart.c
> +++ b/bsps/arm/xilinx-zynq/console/zynq-uart.c
> @@ -262,12 +262,16 @@ static void zynq_uart_write_support(
> #endif
> }
>
> +/*
> + * Disable this because the initialization is done by code generated
> + * by the Xilinx code generator.
> + */
The main purpose of the set attributes function is to apply the settings
specified by the user via the Termios interface. Returning false just
indicates that this function is not implemented. If you want to hide
this fact from the user, then you can simply return true ...
This assumes all UART hardware supports all possible options. There are many
UARTs that do not. I am not sure if there are errno's that could determine the
nature of the failure.
We discussed this alternative with Chris and this was the end result.
git blame shows that Chris added the if 0 and then you added the return false
which broke the callers. From that point forward, no interactive test ran
successfully.
The driver provides no attribute functionality so removing the function means
the default behavior in termios is used to manage the error. It was decided
having the default behavior was best until the driver provided the
functionality.
The Zynq is sort of strange in relation to default settings for UARTs. The
SystemZ component in the Xilinx design tool provides settings for the UART and
this ends up in the ps7_init.c file generated by the SDK and built into the FSBL
bootloader. This code paints all registers including the UART at boot time.
Adding UART attribute setting code to the RTEMS driver would result in the
SystemZ settings being overridden by RTEMS which is confusing. I am not sure how
this can be handled without there being some conflict. RTEMS would need to set
the baudrate to 115200 to match the SystemZ default.
So even if we implement the set attributes we have the problem to figure
out in which state the UART is during initialization? My hope was
eventually someone will implement it. Since nobody requested the set
attributes function in a couple of years, I think it is all right to
just remove it and return no error.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
