Re: Bug in 8520.c - port.type not set for serial console

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Monday 06 June 2005 9:03 am, Jim Ramsay wrote:
> On 5/31/05, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > On Monday 30 May 2005 4:38 pm, Jim Ramsay wrote:
> > > I am attempting to get the 8520.c driver's serial console working with
> > > a 16550A UART implementation, and have run into what I consider to be
> > > a bug:  In short, the proper 'port.type' for this serial port is not
> > > set until the module init (serial8250_init) is called, so the FCR is
> > > set incorrectly during serial8250_console_init for any port type which
> > > is different than UNKNOWN.
> > >
> > > The exact problem is that the FCR is being set to '0x0' for a port
> > > type of 'UNKNOWN', when for my specific 16550A, it should be set to
> > > '0xC1' - and this makes my screen fill with empty characters instead
> > > of the printk output I need.
> > 
> > Shouldn't a 16550A UART work correctly with FCR==0x0, i.e., with FIFOs
> > disabled?  Is your UART broken?
> 
> That's a good question.  I'll me looking into this in the near future.
> 
> > Serial console output is always polled, one character at a time, so
> > you shouldn't need FIFOs until later.
> 
> True, as long as it works that way... so far I haven't seen it
> actually function properly yet with FCR set to 0.

On all the UARTs I've seen, it works with FCR=0.  Hence my suspicion
of your device.

The problem is that most architectures supply SERIAL_PORT_DFNS,
which are compiled-in mappings of /dev/ttyS device names to
specific devices, so 8250.c knows about and uses those devices
before they're properly identified and initialized.

If you can remove your SERIAL_PORT_DFNS (and discover the devices
at boot-time via a mechanism like ACPI or PCI enumeration), then
8250.c won't start using the port until it's correctly initialized.

That means the serial console won't start working until later, of
course.  If you need a serial console early, I think you should use
something like 8250_early.c.  That uses "console=uart,io,0x3f8", so
you don't have to have compiled-in knowledge of the device names.
It currently initializes the UART with FCR=0 also, but it would
be reasonable to add a "no-init" option to just use the device in
the state firmware left it in.