Re: Bitrotting serial drivers

Re: Bitrotting serial drivers

[Ralf Baechle]

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

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

Actually Pete Popov (ppopov@embeddedalley.com) 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

Re: Bitrotting serial drivers

[Pete Popov]

Ralf Baechle wrote:
> On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote:
> 
> 
>>>au1x00_uart
>>>-----------
>>>
>>>Maintainer: unknown (akpm - any ideas?)
>>
>>Ralf.
> 
> 
> Actually Pete Popov (ppopov@embeddedalley.com) who I put on the cc.

Thanks :)

>>>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.

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.

>>>- 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.

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

Re: Bitrotting serial drivers

[Russell King]

On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote:
> >>>- __register_serial, register_serial, unregister_serial
> >>>  (this driver doesn't support PCMCIA cards, all of which are based on
> >>>   8250-compatible devices.)
>
> 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.

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

Re: Bitrotting serial drivers

[Pete Popov]

Russell King wrote:
> On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote:
> 
>>>>>- __register_serial, register_serial, unregister_serial
>>>>> (this driver doesn't support PCMCIA cards, all of which are based on
>>>>>  8250-compatible devices.)
>>
>>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.
> 
> 
> 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.

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

Thanks,

Pete

Re: Bitrotting serial drivers

[Michael Stickel]

Ralf Baechle wrote:

>On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote:
>  
>
>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
>  
>
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

Re: Bitrotting serial drivers

[Stanislaw Skowronek]

> 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,...).

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

Stanislaw

Re: Bitrotting serial drivers

[Pete Popov]

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

Well, it basically is.

> Most of the difference seems to be the PCI stuff, that has been removed 
> and the access method.

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

Re: Bitrotting serial drivers

[Michael Stickel]

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

Re: Bitrotting serial drivers

[Ralf Baechle]

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

Re: Bitrotting serial drivers

[Ulrich Eckhardt]

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

Re: Bitrotting serial drivers

[Pete Popov]

Ulrich Eckhardt wrote:
> 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. 

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

Pete

> 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
> 
> 

RE: Bitrotting serial drivers

[Joseph Chiu]

Hmmm, that's news to me!  I've been using console=ttyS0,115200  console=ttyS0,9600 and console= (no console) forever.

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ulrich Eckhardt
> Sent: Monday, March 21, 2005 12:51 PM
> To: linux-mips@linux-mips.org
> Subject: Re: Bitrotting serial drivers
> 
> 
> 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
> 
> 

RE: Bitrotting serial drivers

[Joseph Chiu]

Hmmm, that's news to me!  I've been using console=ttyS0,115200  console=ttyS0,9600 and console= (no console) forever.

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ulrich Eckhardt
> Sent: Monday, March 21, 2005 12:51 PM
> To: linux-mips@linux-mips.org
> Subject: Re: Bitrotting serial drivers
> 
> 
> 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
> 
> 

Re: Bitrotting serial drivers

[Ulrich Eckhardt]

On Monday 21 March 2005 21:57, Pete Popov wrote:
> Ulrich Eckhardt wrote:
> > 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.
>
> Well, come on, I know that much works :) Which board and kernel rev?
>

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

Re: Bitrotting serial drivers

[Michael Stickel]

Ulrich Eckhardt wrote:

>On Monday 21 March 2005 21:57, Pete Popov wrote:
>  
>
>>Ulrich Eckhardt wrote:
>>    
>>
>>>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.
>>>
Did you try console=ttyS0,*
I also had some problems with the 2.6 release and the serial console.

Michael

Re: Bitrotting serial drivers

[Michael Stickel]

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