Mason <slash.tmp@xxxxxxx> writes:
> Hello everyone,
>
> I am working on a Tango4 SoC, which has the same "weird register layout"
> as Au1x00/RT288x UART. The verilog says "The uartcore is compatible with
> National 16550D UART", and the doc says "The UART is almost compatible
> with National Semiconductor's 16550".
>
> I have a few questions with respect to 8250_core.c
>
> In no particular order:
>
> (I'm having a hard time following the function pointers.)
> I don't think serial8250_config_port() calls autoconfig() right?
> i.e. I don't think UART_CONFIG_TYPE is set when port->iotype == UPIO_AU
>
> I don't see where port.type is set, and to what (PORT_16550A?)
> And how fifo_size and tx_loadsz are set up?
Some parameters can be configured in your device tree entry for the UART,
see of_serial.c.
> The PORT_16550A entry doesn't set UART_CAP_EFR, yet autoconfig_16550a()
> tries to read UART_EFR... how come?
To check for a couple of variants that do have such a register, just
like the comments say.
> The RT3050 (which is supposed to be compatible with the RT288x?) has
> a scratch register. But the au_io_{in,out}_map lookup tables don't
> map UART_SCR, and some functions seem to use the scratch register,
> such as serial8250_console_write
The scratch register is only used for two things:
1. To check if the scratch register exists in order to distinguish an
original 8250 from a 16450.
2. To tell if the UART lost state during a suspend/resume cycle. If the
scratch register doesn't exist, the port will simply be reinitialised
same as if it existed and got corrupted while suspended.
The reason UART_SCR isn't mapped in the tables is probably that the
Alchemy, for which this was originally written, doesn't have a scratch
register (offset 0x24 has a different function entirely there), and
nothing important depends on it for the Ralink ones. The driver works
as is for Tango3, so odds are it will work for Tango4 as well.
--
Måns Rullgård
mans@xxxxxxxxx
--
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
