Subject: Re: Bitrotting serial drivers

From: Ralf Baechle <[email-masked]>
Date: Sun, 20 Mar 2005 22:40:29 +0000

On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote:

> > au1x00_uart
> > -----------
> > 
> > Maintainer: unknown (akpm - any ideas?)
> 
> Ralf.

Actually Pete Popov ([email-masked]) who I put on the cc.

> > This is a complete clone of 8250.c, which includes all the 8250-specific
> > structure names.
> > 
> > Specifically, I'd like to see the following addressed:
> > 
> > - Please clean this up to use au1x00-specific names.
> > - this driver is lagging behind with fixes that the other drivers are
> >   getting.  Is au1x00_uart actually maintained?

Sort of; much of the Alchemy development effort is still going into 2.4.

> > - the usage of UPIO_HUB6
> >   (this driver doesn't support hub6 cards)
> > - __register_serial, register_serial, unregister_serial
> >   (this driver doesn't support PCMCIA cards, all of which are based on
> >    8250-compatible devices.)
> > - early_serial_setup
> >   (should we really have the function name duplicated across different
> >    hardware drivers?)

No argument here.  Pete says the AMD Alchemy UART is just different enough
to be hard to handle in the 8250 and so the driver is just an ugly
chainsawed version of the 8250.c

> > The main reason is I wish to kill off uart_register_port and
> > uart_unregister_port, but these drivers are using it.

  Ralf

---

From: Pete Popov <[email-masked]>
Date: Sun, 20 Mar 2005 14:51:40 -0800

> Actually Pete Popov ([email-masked]) who I put on the cc.

Thanks :)

> Sort of; much of the Alchemy development effort is still going into 2.4.

It works and no one has complained about any bugs. But you're right, fixes going 
into other drivers have not made it into this one.

>>>uart_unregister_port, but these drivers are using it.

I tried a couple of times to cleanly add support to the 8250 for the Au1x 
serial. The uart is just different enough to make that hard, though I admit I 
never spent too much time on it. Sounds like it's time to revisit it again.

Pete

---

From: Russell King <[email-masked]>
Date: Sun, 20 Mar 2005 23:24:38 +0000

> never spent too much time on it. Sounds like it's time to revisit it again.

I would prefer to have a patch to remove (or ack to do so myself) the
above three mentioned functions so I can avoid breaking your driver,
rather than a large update to it.

Thanks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

---

From: Pete Popov <[email-masked]>
Date: Sun, 20 Mar 2005 15:42:27 -0800

> rather than a large update to it.

Go for it. I'll test the driver afterwards and think about getting it into the 
8250 again.

Thanks,

Pete

---

From: Michael Stickel <[email-masked]>
Date: Mon, 21 Mar 2005 08:45:33 +0100

>chainsawed version of the 8250.c
Even if I don't make me a lot of friends, the au1x00 driver seems to be 
a hack.

Most of the difference seems to be the PCI stuff, that has been removed 
and the access method.
Shouldn't we have a driver for the chip and one driver for each access 
method (isa,pci,...).
The access method should handle register access and the bus abstraction.
I have a lot of problems with the au1x00 serial driver, because I use it 
together
with a PCMCIA serial port card.

Michael

---

From: Stanislaw Skowronek <[email-masked]>
Date: Mon, 21 Mar 2005 10:06:20 +0100 (MET)

> Shouldn't we have a driver for the chip and one driver for each access 

Right! I'm entirely with you. SGI Octane required hacks to the 8250 driver
just to get a new access method.

Stanislaw

---

From: Pete Popov <[email-masked]>
Date: Mon, 21 Mar 2005 01:19:47 -0800

> Even if I don't make me a lot of friends, the au1x00 driver seems to be 

Well, it basically is.

> Most of the difference seems to be the PCI stuff, that has been removed 

There were a bunch of differences including how you program the baud rate, the 
addresses of the registers, and if I remember correctly, additional/different 
registers. To cleanly get the au1x support into the 8250 driver, some additional 
abstraction was necessary and I just never had the time to do it.

Pete

---

From: Michael Stickel <[email-masked]>
Date: Mon, 21 Mar 2005 13:12:08 +0100

On Monday 21 March 2005 10:19, Pete Popov wrote:
> There were a bunch of differences including how you program the baud rate,

You mentioned the baudrate. There is one thing that had happend to me.
On the au1x00 the baud_base  is 0 by default. In the serial driver there is a 
division by baud_base, that ends up in a an exception. How could we handle 
that. For the moment I set it to a default before it is used:

if (baud_base == 0L)
  baud_base = 115200;

Which is also a hack. How can we get the correct baud_base for a pcmcia based 
serial-port.

> the addresses of the registers, and if I remember correctly,
> additional/different registers. To cleanly get the au1x support into the
> 8250 driver, some additional abstraction was necessary and I just never had
> the time to do it.

We should have a resource for the register access and the serial driver should 
not care about what it is (memory,io,au1x00,multiport,...). It should just 
use the resource to access the chip. The resource can be a "virtual resource" 
like the multiport cards that have an index register.

The serial port needs a second resource that is the interrupt.

Michael

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 21 Mar 2005 12:38:46 +0000

On Mon, Mar 21, 2005 at 01:12:08PM +0100, Michael Stickel wrote:

It would be useful if you had not truncated the cc list of this thread.
The people that deciede on the serial drivers fate are now no longer
receiving it.

  Ralf

---

From: Ulrich Eckhardt <[email-masked]>
Date: Mon, 21 Mar 2005 21:51:21 +0100

On Sunday 20 March 2005 23:51, Pete Popov wrote:
> It works and no one has complained about any bugs. 

I hereby do complain that it doesn't work. ;)

I'd give more details, but I'm neither at work nor did I investigate the 
situation properly. What I remember trying is to add 'console=/dev/ttyS0' or 
somesuch to the commandline, but couldn't get it to work there. The funny 
thing is that when I use the GDB support over serial line (which seems to use 
a primitive, stripped-down version of a serial driver) it works, I can then 
redirect boot messages via 'console=gdb'.

Uli

---

From: Pete Popov <[email-masked]>
Date: Mon, 21 Mar 2005 12:57:12 -0800

Ulrich Eckhardt wrote:
> somesuch to the commandline, but couldn't get it to work there. 

Well, come on, I know that much works :) Which board and kernel rev?

Pete

> The funny

---

From: Ulrich Eckhardt <[email-masked]>
Date: Mon, 21 Mar 2005 23:07:18 +0100

On Monday 21 March 2005 21:57, Pete Popov wrote:
> > situation properly. What I remember trying is to add 'console=/dev/ttyS0'
> > or somesuch to the commandline, but couldn't get it to work there.
>

DB1100 derivative running 2.6.something from linux-mips CVS. Maybe it's just 
PEBKAC though, I can't rule that out. Maybe I'll get to trying tomorrow 
again, but it's not on the top of my priorities - that's rooting from CF 
currently.

Uli

---

From: Michael Stickel <[email-masked]>
Date: Tue, 22 Mar 2005 08:28:00 +0100

>>>or somesuch to the commandline, but couldn't get it to work there.
Did you try console=ttyS0,*
I also had some problems with the 2.6 release and the serial console.

Michael

---

From: Michael Stickel <[email-masked]>
Date: Tue, 22 Mar 2005 10:58:35 +0100

If we leave the driver for the au1x00 as it is it should not have the 
register_serial / unregister_serial functions and it should be renamed to 
something else, e.g. ttySAxxx like it is done for the internal serial port of 
the strongarm (sa1100).

I have thought about the serial driver and came along this.
I we take a look at the hardware, we have a chip, the 8250 and its successors 
and the chip is integrated into some kind of hardware. So the chip has an 
interface. It has some address lines for register access, it has data lines 
and some controll lines. It also has an interrupt pin, some (GP)IO-Pins, that 
are freely programmable and a clock input.  The chip is integrated thru some 
interface as I mentioned before. It can be an ISA-IO card or a PCI card or a 
multiport card, where more than one chip is accessed thru the same io-range 
and the hip to access is selected thru a single register. The au1x00 serial 
driver is like an ISA card except that the chip is mapped to a memory region 
instead of an io-region and the fact, that we can calculate the baud_base 
using the pll configuration of the au1x00, if we assume a 12MHz oscilator, 
which is standard for the au1x00.

We need some access methods to access the chip registers, some way to handle 
intterupts, some way to deal with the gpio-pins, and we need a way to get the 
clock input of the chip. What should the serial-chip driver know about and 
what should the card driver know about.

It's like the streams concept, where the chip driver does not know how to 
access the chip or what resources it uses, but what to do with the chip.

Regards,
Michael