Hello.
Pantelis Antoniou wrote:
BTW, can anybody enlighten me why 8250_au1x00.c came into being
at all?
Its only function seems to register the UART platform devices,
the thing
that is usually done in the board setup code, i. e. I'd rather
have it in arch/mips/au1000/common/platform.c (however, 8250.c
should have been able to filter out ports with UPIO_AU in case
CONFIG_SERIAL_8250_AU1X00 undefined)...
Seemed like a good idea at the moment to follow the already
existing convention.
Already existing convention is as per Sergei's mail actually - to
have the
platform device registration in arch/*. The others which you
thought were
convention there (accent, boca, fourport, hub6, mca) are all for add-in
cards and aren't architecture specific.
Hence, they can't live in arch/*.
So yes, 8250_au1x00.c breaks the established convention because it
isn't
an add-in card.
Thanks for clarification.
Now another question to Pantelis: IIUC, the Alchemy UART platform
devices have UPF_SKIP_TEST set because of the Alchemy docs claiming
that UARTs other than UART3 don't have MCR/MSR and only UART3 does
have the full set of the modem control/status lines? Were they
indeed failing the loopback test for you? Asking because on DBAu1550
board all (enabled) UARTs do pass the loopback test if I get rid of
this flag (however, Au1550 datasheet says MCR/MSR exists on all
UARTs, just no modem pins exist on UART0, and only RTS-/CTS- pair on
UART1 -- and the bits having no correspoding pins seem to be tied
high internally).
If I'm correct, the driver seems inconsistent in how it handles
UART_BUG_NOMSR flag, only checking it when deciding whether to enable
the modem status interrupts or not while actually it should have been
checked in serial8250_set_mctrl() and check_modem_status () as well...
It also looks like the driver doesn't use Alchemy UARTs to their
full potential currently: UART3 has not only full set of modem lines,
but also is capable of the auto flow control (UART1 on Au1550 also
is). (Making use of these features howewer are complicated by the
auto flow control being only available in the late steppings of
Au1500 and UART3 modem pins being multiplexed with GPIO...)
PS: CCing linux-mips to keep people here informed. :-)
Yes, 1550 has proper UARTs on all port, but not 1200 ;)
No, it doesn't have "proper" UARTs on all ports (like all the other
Alchemies), it's just said it has MCR/MSR on UART0/1 as well as on UART3.
Actually, Au1200 also does, according to its datasheet.
Somehow I thought that hacking 8250 to support two different Au's (1550
& 1200)
wouldn't go down well; so I chickened out & settled for a subset that
would work on
both. Feel free to fight your way through to support all the
functionality you
require.
Well, now I certainly have no time for enabling any features, even for
fixing buglets. So, if anybody of the linux-mips readers cares enough, it's
their call... :-)
At least UART_BUG_NOMSR handling should be extended if MCR/MSR are indeed
missing on some SOCs.
And since 0 in the bit 7 (U3) bit of sys_pinfunc determines if UART3 modem
control/status are used for GPIO, this is also worth checking somewhere (if
one wants to support the full set of the modem lines)...
Pantelis
WBR, Sergei
