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

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

[Jim Ramsay]

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.  It appears that after some time (once
the kernel actually calls serial8250_init) the problem clears up, but
I still lose a large section of the output before this point.

The proper flags are sitting there in the uart_config array for the
proper type, and this type is properly deduced by the 'autoconfig'
routine that eventually gets called by serial8250_init.  The problem
is that the autoconfig is isn't called by serial8250_console_init
which of course happens much earlier than serial8250_init.

I have a workaround that works for me, telling the
serial8250_set_termios() routine to only set the FCR if the type is
not UNKNOWN, changing
    if (up->port.type != PORT_16750 ) {
to
    if (up->port.type != PORT_16750 && up->port.type != PORT_UNKNOWN) {

This will leave the FCR at whatever it was at boot time, which for me
is correct.

Would this be a "good enough" fix in general, or would there be a
better way of doing this?

I suppose the other way would be to duplicate some of what
serial8250_init does (like call 'autoconfig') in
serial8250_console_init, but I haven't tried this yet... maybe it
depends on too much kernel magic to be called as early as
'console_init'?

Any suggestions on the best way to fix this would be great, I'd be
happy to develop this more, test a bit, and submit a patch.

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

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

[Bjorn Helgaas]

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?

Serial console output is always polled, one character at a time, so
you shouldn't need FIFOs until later.

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

[Jim Ramsay]

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.

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

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

[Bjorn Helgaas]

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.