Serial core problems on embedded PPC

Serial core problems on embedded PPC

[David Gibson]

I've been trying to get the new serial core stuff working on a PPC 4xx
machine (an EP405 board, specifically).  This is proving more
difficult than I expected.

In 8250.c, it appears that in order for a port to be used for the
serial console it must be defined "old style" with SERIAL_PORT_DFNS,
rather than being registered with register_serial() (because
serial8250_console_setup() indexs into the serial8250_ports array)).
This presents a small problem for 4xx, since it's serial ports are
memory mapped and the new old_serial_port structure can't represent
these.  I added support for these into 8250.c, but ran into further
troubles.

The kernel now gets into an infinite loop when trying to open
/dev/console in init().  The loop is occuring in tty_open() - the open
fails and it loops back to the retry_open: label.  This seems to be
happening because the uart_port structure is ending up with the type
field set to PORT_UNKNOWN.  However, I'm getting confused attempting
to work out where this field ought to be set, and why it isn't.

The current plethora of similar-but-not-the-same structures describing
serial ports (serial_state, serial_struct, uart_port, old_serial_port)
is also rather confusing.  I'm guessing some of these are deprecated
and remain only as an aid to transition, but I'm not sure which.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

Re: Serial core problems on embedded PPC

[Russell King]

On Mon, Jul 29, 2002 at 02:08:24PM +1000, David Gibson wrote:
> I've been trying to get the new serial core stuff working on a PPC 4xx
> machine (an EP405 board, specifically).  This is proving more
> difficult than I expected.

It's vital that you mention the kernel version you're using; some of
these problems sound like 2.5.28.

> In 8250.c, it appears that in order for a port to be used for the
> serial console it must be defined "old style" with SERIAL_PORT_DFNS,
> rather than being registered with register_serial() (because
> serial8250_console_setup() indexs into the serial8250_ports array)).
> This presents a small problem for 4xx, since it's serial ports are
> memory mapped and the new old_serial_port structure can't represent
> these.

There is no easy solution for this.  Alan said we must not drop support
for serial console initialisation early on in the kernel setup, which
means before the memory subsystems are initialised.

> I added support for these into 8250.c, but ran into further troubles.

I suspect a 2.5.28 kernel; please confirm and we'll that it from there.

> The current plethora of similar-but-not-the-same structures describing
> serial ports (serial_state, serial_struct, uart_port, old_serial_port)
> is also rather confusing.  I'm guessing some of these are deprecated
> and remain only as an aid to transition, but I'm not sure which.

I don't see there being an easy way to kill this off:

1. serial_struct is a userspace API.
2. old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be
   changed because (mainly) ppc uses it elsewhere.  Other architectures
   seem to do the same sort of thing.

Unless ppc and others are willing to put up with major breakage when I
change asm/serial.h, I don't see this getting cleaned up.  Comments on
this area welcome.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Serial core problems on embedded PPC

[Tom Rini]

On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:

> Unless ppc and others are willing to put up with major breakage when I
> change asm/serial.h, I don't see this getting cleaned up.  Comments on
> this area welcome.

Well, what changes do you have in mind?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Russell King]

On Mon, Jul 29, 2002 at 07:44:08AM -0700, Tom Rini wrote:
> On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
> > Unless ppc and others are willing to put up with major breakage when I
> > change asm/serial.h, I don't see this getting cleaned up.  Comments on
> > this area welcome.
> 
> Well, what changes do you have in mind?

Firstly, apologies to Tom for turning this into a general discussion
mail.  At the request of Tom, this message is also CC:'d to the PPC
devel lists.

There's quite a lot in here, so please, when replying edit out stuff
your not replying to.  Thanks.


1. Serial port initialisation
-----------------------------

Firstly, one thing to bear in mind here is that, as Alan says "be nice
to make sure it was much earlier".  I guess Alan's right, so we can get
oopsen out of the the kernel relatively easily, even when we're using
framebuffer consoles.

I'm sure Alan will enlighten us with his specific reasons if required.

There have been several suggestions around on how to fix this table:

a. architectures provide a sub-module to 8250.c which contains the
   per-port details, rather than a table in serial.h.  This would
   ideally mean removing serial.h completely.  The relevant object
   would be linked into 8250.c when 8250.c is built as a module.

b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends
   each containing the parameters for the specific cards and handle it
   as above.

c. make it the responsibility of user space to tell the kernel about
   many serial ports, and leave just the ones necessary for serial
   console in the kernel.  (see issue 2 below)

d. we keep serial.h, make it 8250-compatible ports only, and change
   CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT
   This is the simplest and least likely to break other code.  On the
   other hand, we end up hauling the ISA table and struct old_serial_port
   into 2.6.


2. setserial API
----------------

This is actually tied closely into another issue; I'd like to get rid
of this silly idea where we're able to open serial ports that don't
exist (ie, their UART is "unknown").  This behaviour appears to be for
the benefit of setserial to allow it to modify port base addresses and
interrupt levels, etc.  Removing this facility would require a new API
for such things.  The best suggestion made so far is to do something
like:

# echo "add 0x2e8,3,autoconfig" >/dev/serialctl
# echo "remove 0x2e8" >/dev/serialctl

(or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)

where we have "add ioport,irq,flags" and "remove ioport" (note that
mmio ports aren't covered here since they require ioremap games which
tends to be card specific!)

Why make this change?  Well, we have quite a lot of baggage being
dragged around to support configuration of an open port and being
able to open a non-existent port.  I'd really like to get rid of
this excess baggage.


3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc
---------------------------------------------------------

All the above are serial ports of various types.  It has been expressed
several times that people would like to see all of them appear as
/dev/ttyS* (indeed, there was an, erm, rather heated discussion about
it a couple of years ago.)  I'm going to be neutral on this point
here.

There are several issues surrounding this:

a. The serial core.c is very almost capable of handling this abstraction,
   with one exception - a registered port can only be in one group at
   one time.  This restriction is brought about because of the way the
   tty layer handles its tty ports.

   (Handling dual registrations in two different majors gets _really_
    messy - eg, you two built-in 16550A ports and two SA1100 ports
    taking up ttyS0 to ttyS3.  You then add a 16550A PCMCIA modem,
    which becomes ttyS4.  Oh, and the SA1100 ports are also appearing
    as ttySA0 and ttySA1.  _really_ messy.  No thanks.)

b. serial consoles.  Each hardware driver handles its serial consoles
   by itself, and if you have two or more hardware drivers built in
   with serial console support, you need to be able to tell them apart
   with the console= kernel parameter.

   Again, this could be solvable if we have one "ttyS" view of everything
   (core.c would then be responsible for registering the console with
    printk.c and passing the various methods off to the relevant
    hardware).

c. People with many serial ports.  We _could_ change the device number
   allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
   device numbers so we end up with the same number of port slots
   available for those with many many serial ports in their machines.



-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Tom Rini]

On Mon, Jul 29, 2002 at 06:17:02PM +0100, Russell King wrote:

 
> 1. Serial port initialisation
> -----------------------------
> 
> Firstly, one thing to bear in mind here is that, as Alan says "be nice
> to make sure it was much earlier".  I guess Alan's right, so we can get
> oopsen out of the the kernel relatively easily, even when we're using
> framebuffer consoles.
> 
> I'm sure Alan will enlighten us with his specific reasons if required.
> 
> There have been several suggestions around on how to fix this table:
> 
> a. architectures provide a sub-module to 8250.c which contains the
>    per-port details, rather than a table in serial.h.  This would
>    ideally mean removing serial.h completely.  The relevant object
>    would be linked into 8250.c when 8250.c is built as a module.

I think this would work best.  On PPC this would allow us to change the
mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
(especially if we do the automagic <platforms/platform.h> or
<asm/platform.h> bit that's been talked about in the past) magic and we
could use that object file as well in the bootwrapper as well.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Christoph Plattner]

Ad "setserial API":

Please use /proc/serialdev (or similar), *NOT* a `/dev' entry !!
This is typical `/proc'-FS stuff !
(See SCSI: echo "scsi add-single-device 0 0 4 0" > /proc/scsi/scsi   
!!!)

Christoph P.


Russell King wrote:
> 
> On Mon, Jul 29, 2002 at 07:44:08AM -0700, Tom Rini wrote:
> > On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
> > > Unless ppc and others are willing to put up with major breakage when I
> > > change asm/serial.h, I don't see this getting cleaned up.  Comments on
> > > this area welcome.
> >
> > Well, what changes do you have in mind?
> 
> Firstly, apologies to Tom for turning this into a general discussion
> mail.  At the request of Tom, this message is also CC:'d to the PPC
> devel lists.
> 
> There's quite a lot in here, so please, when replying edit out stuff
> your not replying to.  Thanks.
> 
> 1. Serial port initialisation
> -----------------------------
> 
> Firstly, one thing to bear in mind here is that, as Alan says "be nice
> to make sure it was much earlier".  I guess Alan's right, so we can get
> oopsen out of the the kernel relatively easily, even when we're using
> framebuffer consoles.
> 
> I'm sure Alan will enlighten us with his specific reasons if required.
> 
> There have been several suggestions around on how to fix this table:
> 
> a. architectures provide a sub-module to 8250.c which contains the
>    per-port details, rather than a table in serial.h.  This would
>    ideally mean removing serial.h completely.  The relevant object
>    would be linked into 8250.c when 8250.c is built as a module.
> 
> b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends
>    each containing the parameters for the specific cards and handle it
>    as above.
> 
> c. make it the responsibility of user space to tell the kernel about
>    many serial ports, and leave just the ones necessary for serial
>    console in the kernel.  (see issue 2 below)
> 
> d. we keep serial.h, make it 8250-compatible ports only, and change
>    CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT
>    This is the simplest and least likely to break other code.  On the
>    other hand, we end up hauling the ISA table and struct old_serial_port
>    into 2.6.
> 
> 2. setserial API
> ----------------
> 
> This is actually tied closely into another issue; I'd like to get rid
> of this silly idea where we're able to open serial ports that don't
> exist (ie, their UART is "unknown").  This behaviour appears to be for
> the benefit of setserial to allow it to modify port base addresses and
> interrupt levels, etc.  Removing this facility would require a new API
> for such things.  The best suggestion made so far is to do something
> like:
> 
> # echo "add 0x2e8,3,autoconfig" >/dev/serialctl
> # echo "remove 0x2e8" >/dev/serialctl
> 
> (or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)
> 
> where we have "add ioport,irq,flags" and "remove ioport" (note that
> mmio ports aren't covered here since they require ioremap games which
> tends to be card specific!)
> 
> Why make this change?  Well, we have quite a lot of baggage being
> dragged around to support configuration of an open port and being
> able to open a non-existent port.  I'd really like to get rid of
> this excess baggage.
> 
> 3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc
> ---------------------------------------------------------
> 
> All the above are serial ports of various types.  It has been expressed
> several times that people would like to see all of them appear as
> /dev/ttyS* (indeed, there was an, erm, rather heated discussion about
> it a couple of years ago.)  I'm going to be neutral on this point
> here.
> 
> There are several issues surrounding this:
> 
> a. The serial core.c is very almost capable of handling this abstraction,
>    with one exception - a registered port can only be in one group at
>    one time.  This restriction is brought about because of the way the
>    tty layer handles its tty ports.
> 
>    (Handling dual registrations in two different majors gets _really_
>     messy - eg, you two built-in 16550A ports and two SA1100 ports
>     taking up ttyS0 to ttyS3.  You then add a 16550A PCMCIA modem,
>     which becomes ttyS4.  Oh, and the SA1100 ports are also appearing
>     as ttySA0 and ttySA1.  _really_ messy.  No thanks.)
> 
> b. serial consoles.  Each hardware driver handles its serial consoles
>    by itself, and if you have two or more hardware drivers built in
>    with serial console support, you need to be able to tell them apart
>    with the console= kernel parameter.
> 
>    Again, this could be solvable if we have one "ttyS" view of everything
>    (core.c would then be responsible for registering the console with
>     printk.c and passing the various methods off to the relevant
>     hardware).
> 
> c. People with many serial ports.  We _could_ change the device number
>    allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
>    device numbers so we end up with the same number of port slots
>    available for those with many many serial ports in their machines.
> 
> --
> Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
>              http://www.arm.linux.org.uk/personal/aboutme.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

-- 
-------------------------------------------------------
private:	christoph.plattner@gmx.at
company:	christoph.plattner@alcatel.at

Re: 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Benjamin Herrenschmidt]

>> a. architectures provide a sub-module to 8250.c which contains the
>>    per-port details, rather than a table in serial.h.  This would
>>    ideally mean removing serial.h completely.  The relevant object
>>    would be linked into 8250.c when 8250.c is built as a module.
>
>I think this would work best.  On PPC this would allow us to change the
>mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
>(especially if we do the automagic <platforms/platform.h> or
><asm/platform.h> bit that's been talked about in the past) magic and we
>could use that object file as well in the bootwrapper as well.

Especially, please, let's avoid once for all statically defined table,
on PPC (specifically on pmac) the table is really dynamic, and
the "legacy ports" (if any) may not be ttyS0..1, but could well be
2..3, or higher, all this having to be decided at runtime for both
built-in driver and modular (so eraly_serial_setup isn't good).

I quite like the sub-module mecanism. I'd rather have it done the
opposite though. I don't care that much about sharing those files
with the bootloader, and i'd rather see the core serial code beeing
a submodule of the arch specific module.

Typically, that would give us:

 - 8250_legacy.c would load 8250 core, probe legacy ports and
instanciate them for typical x86 setup
 - 8250_ppc.c would instanciate known ports on PReP or CHRP machines
and do nothing on pmac
 - 8250_pci.c would be a pci_driver and instanciate ports for a given
PCI card
 - 8250_cs.c would be a pcmcia driver and instanciate ports for a 
given PCMCIA modem card

etc... And of course, we can have an arbitrary set of the above loaded
instanciating ports are they are found.

Ben.

Re: 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Matt Porter]

On Mon, Jul 29, 2002 at 10:43:41AM -0700, Tom Rini wrote:
> 
> On Mon, Jul 29, 2002 at 06:17:02PM +0100, Russell King wrote:
> 
> 
> > 1. Serial port initialisation
> > -----------------------------
> >
> > Firstly, one thing to bear in mind here is that, as Alan says "be nice
> > to make sure it was much earlier".  I guess Alan's right, so we can get
> > oopsen out of the the kernel relatively easily, even when we're using
> > framebuffer consoles.
> >
> > I'm sure Alan will enlighten us with his specific reasons if required.
> >
> > There have been several suggestions around on how to fix this table:
> >
> > a. architectures provide a sub-module to 8250.c which contains the
> >    per-port details, rather than a table in serial.h.  This would
> >    ideally mean removing serial.h completely.  The relevant object
> >    would be linked into 8250.c when 8250.c is built as a module.
> 
> I think this would work best.  On PPC this would allow us to change the
> mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
> (especially if we do the automagic <platforms/platform.h> or
> <asm/platform.h> bit that's been talked about in the past) magic and we
> could use that object file as well in the bootwrapper as well.

I think this would be the cleanest method as well.  Especially when we
recognize that the asm-ppc/serial.h situation will only get worse
over time.  Every embedded PPC board designer has a unique location
for his 16550 UART(s) and we just keep adding more preprocessor
cruft for each port.  This should let us keep this board-specific
info in our board port files...more abstraction=good.

Regards,
-- 
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

Re: Serial core problems on embedded PPC)

[Tom Rini]

On Mon, Jul 29, 2002 at 08:13:52PM +0200, Benjamin Herrenschmidt wrote:

> >> a. architectures provide a sub-module to 8250.c which contains the
> >>    per-port details, rather than a table in serial.h.  This would
> >>    ideally mean removing serial.h completely.  The relevant object
> >>    would be linked into 8250.c when 8250.c is built as a module.
> >
> >I think this would work best.  On PPC this would allow us to change the
> >mess of include/asm-ppc/serial.h into a slightly cleaner Makefile
> >(especially if we do the automagic <platforms/platform.h> or
> ><asm/platform.h> bit that's been talked about in the past) magic and we
> >could use that object file as well in the bootwrapper as well.
> 
> Especially, please, let's avoid once for all statically defined table,
> on PPC (specifically on pmac) the table is really dynamic, and
> the "legacy ports" (if any) may not be ttyS0..1, but could well be
> 2..3, or higher, all this having to be decided at runtime for both
> built-in driver and modular (so eraly_serial_setup isn't good).

Well, on pmac yes.  But for a good hunk of the rest of the PPC world the
inital ports are static (and as long as new ports, ie pcmcia stuff, is
handled sanely anyhow, I don't think this is an issue).

> I quite like the sub-module mecanism. I'd rather have it done the
> opposite though. I don't care that much about sharing those files
> with the bootloader, and i'd rather see the core serial code beeing
> a submodule of the arch specific module.

Then how do you propose to keep the bootloader working and kill off the
ugly ugly include/asm-ppc/serial.h ?

> Typically, that would give us:
> 
>  - 8250_legacy.c would load 8250 core, probe legacy ports and
> instanciate them for typical x86 setup
>  - 8250_ppc.c would instanciate known ports on PReP or CHRP machines
> and do nothing on pmac
>  - 8250_pci.c would be a pci_driver and instanciate ports for a given
> PCI card
>  - 8250_cs.c would be a pcmcia driver and instanciate ports for a 
> given PCMCIA modem card
> 
> etc... And of course, we can have an arbitrary set of the above loaded
> instanciating ports are they are found.

I _think_ the 8250_cs.c case is seperate in this case.  But most of what
you describe would work fine in the arch-is-a-submodule case.  What I
was thinking of was some makefile bits to something like:
# The true legacy ports, prep/chrp/others.  With a _machine test or
# something.
serial-$(CONFIG_ALL_PPC) += legacy.o
# K2 uses the legacy locations too
serial-$(CONFIG_K2) += legacy.o
# These boards make use of iomem_base/reg shift
serial-$(CONFIG_A) += a_serial.o
serial-$(CONFIG_B) += b_serial.o
...

obj-$(CONFIG_SERIAL_8250) += $(serial-y)

Or so.  Maybe with a rule to turn $(serial-y) into arch_serial.o or
something.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Dan Malek]

Benjamin Herrenschmidt wrote:

> Especially, please, let's avoid once for all statically defined table,
> on PPC (specifically on pmac) the table is really dynamic,

Since all of the discussion here has been around "standard" UARTs.....

I know Russell mentioned this, and it has been discussed in the past,
but I'm most interested in being able to include non-165xx style UARTs
in the /dev/tty<something>.  Systems may be exclusively non-165xx UARTs,
or a mix of both.  The problems to solve are drivers fighting over minor
device numbers and assumptions about the system console.

Thanks.


	-- Dan

Re: 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Remco Treffkorn]

On Monday 29 July 2002 12:09, Dan Malek wrote:
...
> or a mix of both.  The problems to solve are drivers fighting over minor
> device numbers and assumptions about the system console.
>

Drivers need not fight about minor numbers. That can be simply handled:

int get_new_serial_minor()
{
    static int minor;

    return minor++;
}

Any serial driver can call this when it initializes a new uart.
Hot pluggable drivers have to hang on to their minors, and
re-use.

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco@rvt.com   (831) 685-1201

Re: 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Russell King]

On Mon, Jul 29, 2002 at 12:46:42PM -0700, Remco Treffkorn wrote:
> On Monday 29 July 2002 12:09, Dan Malek wrote:
> > or a mix of both.  The problems to solve are drivers fighting over minor
> > device numbers and assumptions about the system console.
> >
> 
> Drivers need not fight about minor numbers. That can be simply handled:
> 
> int get_new_serial_minor()
> {
>     static int minor;
> 
>     return minor++;
> }
> 
> Any serial driver can call this when it initializes a new uart.
> Hot pluggable drivers have to hang on to their minors, and
> re-use.

It's a possible solution, if we get the ability for drivers to hang
on to their minors.  However, I get the feeling that this isn't going
to happen before 2.6.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Matthew Wilcox]

On Mon, Jul 29, 2002 at 06:17:02PM +0100, Russell King wrote:
> 3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc
> ---------------------------------------------------------
> 
> All the above are serial ports of various types.  It has been expressed
> several times that people would like to see all of them appear as
> /dev/ttyS* (indeed, there was an, erm, rather heated discussion about
> it a couple of years ago.)  I'm going to be neutral on this point
> here.

I'm not.  All the issues you mention below go away if we make the rule
that _all_ serial ports are /dev/ttyS*.  Userspace can have symlinks to
ease the transition if necessary.

> c. People with many serial ports.  We _could_ change the device number
>    allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
>    device numbers so we end up with the same number of port slots
>    available for those with many many serial ports in their machines.

Yep, there really are people with >256 serial ports.  It'd be nice to
support them.  Does anything care about the mapping from device name
to char minor?  I suspect the MAKEDEV maintainer will come and squash
me if i suggest moving the mapping for the first 192 serial devices,
but we should be able to reclaim:

Chase serial card (major 17/18), the Cyclades (major 19/20), Digiboard
(major 22/23), Stallion (major 24/25), Specialix (32/33), isdn4linux
(43/44), Comtrol (46/47), SDL RISCom (48/49), Hayes (57/58), Computone
(71/72), Specialix (75/76), PAM (78/79), Comtrol VS (105/106), ISI
(112/113), Technology Concepts (148/149), Specialix RIO (154/155/156/157),
Chase Research (164/165), ACM (166/167), Moxa (172/173), SmartIO
(174/175), USB (188/189), Low-density misc serial ports (204/205),
userspace (208/209) BlueTooth (216/217), A2232 (224/225) ... holy crap,
that's a lot of char dev space ;-)  52 majors.. think what those must
be worth on the open market ;-)

My only real objection (and it's a problem we have at the moment!) is
that serial ports then become like ethernet interfaces.  Add or remove a
card and everything changes number.  Somehow we already survive with this.
I was very careful when adding a new SIIG 4-port serial card to my console
server the other day to notice which card was first in PCI bus scan
order and make sure all my existing machines were hooked up to that one.

The solution to this has to be to name devices by PCI bus ID, but this is
an argument for an entirely different thread ;-)

-- 
Revolutions do not require corporate support.

Re: Serial core problems on embedded PPC

[David Gibson]

On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
> On Mon, Jul 29, 2002 at 02:08:24PM +1000, David Gibson wrote:
> > I've been trying to get the new serial core stuff working on a PPC 4xx
> > machine (an EP405 board, specifically).  This is proving more
> > difficult than I expected.
> 
> It's vital that you mention the kernel version you're using; some of
> these problems sound like 2.5.28.

Sorry.  I'm working off the linuxppc-2.5 BK tree, which is currently
at 2.5.29.

> > In 8250.c, it appears that in order for a port to be used for the
> > serial console it must be defined "old style" with SERIAL_PORT_DFNS,
> > rather than being registered with register_serial() (because
> > serial8250_console_setup() indexs into the serial8250_ports array)).
> > This presents a small problem for 4xx, since it's serial ports are
> > memory mapped and the new old_serial_port structure can't represent
> > these.
> 
> There is no easy solution for this.  Alan said we must not drop support
> for serial console initialisation early on in the kernel setup, which
> means before the memory subsystems are initialised.
> 
> > I added support for these into 8250.c, but ran into further troubles.
> 
> I suspect a 2.5.28 kernel; please confirm and we'll that it from there.

2.5.29 based BK, actually.

> > The current plethora of similar-but-not-the-same structures describing
> > serial ports (serial_state, serial_struct, uart_port, old_serial_port)
> > is also rather confusing.  I'm guessing some of these are deprecated
> > and remain only as an aid to transition, but I'm not sure which.
> 
> I don't see there being an easy way to kill this off:
> 
> 1. serial_struct is a userspace API.

Ok.

> 2. old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be
>    changed because (mainly) ppc uses it elsewhere.  Other architectures
>    seem to do the same sort of thing.

I think PPC's use of asm/serial.h in the bootloader needs to go away
anyway.  Could old_serial_port at least change base_baud to baud_base
to match serial_struct and serial_state.  That way a designated
initializer will work in either context.

> Unless ppc and others are willing to put up with major breakage when I
> change asm/serial.h, I don't see this getting cleaned up.  Comments on
> this area welcome.

Well, the machines I'm working on are totally broken now, so...

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

Re: 3 Serial issues up for discussion

[David S. Miller]

   From: Russell King <rmk@arm.linux.org.uk>
   Date: Mon, 29 Jul 2002 18:17:02 +0100

   d. we keep serial.h, make it 8250-compatible ports only, and change
      CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT
      This is the simplest and least likely to break other code.  On the
      other hand, we end up hauling the ISA table and struct old_serial_port
      into 2.6.
   
My only suggestion here is that, whatever you do, if you keep
serial.h rename it to serial8250.h or similar thanks :-)
   
   b. serial consoles.  Each hardware driver handles its serial consoles
      by itself, and if you have two or more hardware drivers built in
      with serial console support, you need to be able to tell them apart
      with the console= kernel parameter.
   
      Again, this could be solvable if we have one "ttyS" view of everything
      (core.c would then be responsible for registering the console with
       printk.c and passing the various methods off to the relevant
       hardware).
   
On many platforms we know exactly which serial port is for
the console because this is set in some firmware variable.
For others we could say "it's ttyS0 unless stated otherwise
in console=" as one possible solution.

Hey while we're on this topic.  While converting over the sparc
drivers I've come to the conclusion that the serial console write
should be interrupt driven just like any other serial port TX.  The
con->write() algorithm in such a scheme would look something like:

static void
fooserial_console_write(struct console *con, const char *s,
			unsigned int count)
{
	struct uart_fooserial_port *up = CON_TO_UART(con);
	unsigned long flags;
	int i, true_count;

	true_count = count;
	for (i = count - 1; i >= 0; i--) {
		if (s[i] == '\n')
			true_count++;
	}

	spin_lock_irqsave(up, flags);
	poll_until_xmit_buffer_bytes_free(up, true_count);
	append_con_buffer_to_xmit_tail(up, s, count);
	spin_unlock_irqrestore(up, flags);
}

The reason it is done with this "poll until enough space" mechanism
is because we can't sleep.

Upon further consideration this does have some problems.  Because of
the silly '\n' handling this means we have to make sure printk
console output cannot give us more than 1/2 the xmit buffer size
in a single write call else we could potentially never have enough
space free to do the whole write.  We could size the xmit buffer
appropriately for console uart instances, using some value from
the console layer, to solve this.  Or we could make con->write()
calls limit how much they give at one call.  We could indicate this
limit in con->write_max or similar.

Re: 3 Serial issues up for discussion

[David S. Miller]

   From: Remco Treffkorn <remco@rvt.com>
   Date: Mon, 29 Jul 2002 12:46:42 -0700
   
   Drivers need not fight about minor numbers. That can be simply handled:
   
   int get_new_serial_minor()
   {
       static int minor;
   
       return minor++;
   }
   
   Any serial driver can call this when it initializes a new uart.
   Hot pluggable drivers have to hang on to their minors, and
   re-use.

I don't think it's wise to make hot-plug drivers keep track
of the minors they ever use in such a sloppy way.  Why not
make the get_new_serial_minor() thing have a release method
too and then we can keep track of minor allocation in one
place.

Also if I remmove the module for a serial port driver, those minors
should get reused by the next registered uart too.

Finally we can name this all /dev/serialXXX in keeping with Linus's
grand view of /dev/diskXXX et al. (and keeping ttySfoo around for
compat sake for a little while of course :).

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Stuart MacDonald]

From: "Matthew Wilcox" <willy@debian.org>
> I'm not.  All the issues you mention below go away if we make the rule
> that _all_ serial ports are /dev/ttyS*.  Userspace can have symlinks to
> ease the transition if necessary.

I agree.

> but we should be able to reclaim:
>
> Chase serial card (major 17/18), the Cyclades (major 19/20), Digiboard
> (major 22/23), Stallion (major 24/25), Specialix (32/33), isdn4linux
> (43/44), Comtrol (46/47), SDL RISCom (48/49), Hayes (57/58), Computone
> (71/72), Specialix (75/76), PAM (78/79), Comtrol VS (105/106), ISI
> (112/113), Technology Concepts (148/149), Specialix RIO (154/155/156/157),
> Chase Research (164/165), ACM (166/167), Moxa (172/173), SmartIO
> (174/175), USB (188/189), Low-density misc serial ports (204/205),
> userspace (208/209) BlueTooth (216/217), A2232 (224/225) ... holy crap,
> that's a lot of char dev space ;-)  52 majors.. think what those must
> be worth on the open market ;-)

I don't know if reclaiming the USB major is a good idea or not.

..Stu

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Matthew Wilcox]

On Tue, Jul 30, 2002 at 10:36:51AM -0400, Stuart MacDonald wrote:
> I don't know if reclaiming the USB major is a good idea or not.

It's not _all_ of USB, just:

166 char        ACM USB modems
                  0 = /dev/ttyACM0      First ACM modem
                  1 = /dev/ttyACM1      Second ACM modem
                    ...

167 char        ACM USB modems - alternate devices
                  0 = /dev/cuacm0       Callout device for ttyACM0
                  1 = /dev/cuacm1       Callout device for ttyACM1
                    ...

188 char        USB serial converters
                  0 = /dev/ttyUSB0      First USB serial converter
                  1 = /dev/ttyUSB1      Second USB serial converter
                    ...

189 char        USB serial converters - alternate devices
                  0 = /dev/cuusb0       Callout device for ttyUSB0
                  1 = /dev/cuusb1       Callout device for ttyUSB1
                    ...

216 char        USB BlueTooth devices
                  0 = /dev/ttyUB0               First USB BlueTooth device
                  1 = /dev/ttyUB1               Second USB BlueTooth device
                    ...

217 char        USB BlueTooth devices (alternate devices)
                  0 = /dev/cuub0                Callout device for ttyUB0
                  1 = /dev/cuub1                Callout device for ttyUB1
                    ...

I think you were confused with char major 180 which has
printers/mice/scanners/etc on it.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Stuart MacDonald]

From: "Matthew Wilcox" <willy@debian.org>
> I think you were confused with char major 180 which has
> printers/mice/scanners/etc on it.

No, I was wondering if leaving the USB serial major 18[89] alone would
be a better idea. Since posting, I've been thinking that the usb
serial driver presents the same interface to the tty layer as any
other serial device so I guess it's not a bad idea.

..Stu

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Russell King]

On Tue, Jul 30, 2002 at 11:43:13AM -0400, Stuart MacDonald wrote:
> No, I was wondering if leaving the USB serial major 18[89] alone would
> be a better idea. Since posting, I've been thinking that the usb
> serial driver presents the same interface to the tty layer as any
> other serial device so I guess it's not a bad idea.

To be able to suck in USB (and some of the other drivers), two changes
need to be made to the core:

1. the change_speed method needs to be handled differently; we currently
   assume a UART-style implementation here.  We need to change this
   around before 2.6 anyway for ports which don't support all the
   termios settings (SuSv3 requires that any unimplemented features
   retain their original values, so for example if we don't have RTS
   and CTS lines on a particular implementation, CRTSCTS should be
   initially off and not turn on-able.)

2. USB devices want "packets" of data to write rather than the ring-
   buffer we currently use for UARTs.

(time to start ebaying for USB serial devices...)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Greg KH]

On Tue, Jul 30, 2002 at 04:53:51PM +0100, Russell King wrote:
> 2. USB devices want "packets" of data to write rather than the ring-
>    buffer we currently use for UARTs.

The driver could be changed to handle a ring buffer, if it's too tough.
As long as it's ok to grab a very large chunk of data out of the ring
buffer all at once :)

Time to look at the serial changes more closely...

thanks,

greg k-h

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Stuart MacDonald]

From: "Russell King" <rmk@arm.linux.org.uk>
> To be able to suck in USB (and some of the other drivers), two changes
> need to be made to the core:
>
> 2. USB devices want "packets" of data to write rather than the ring-
>    buffer we currently use for UARTs.

This currently isn't a problem I don't think.

> (time to start ebaying for USB serial devices...)

I can see about getting you one of our boards on eval. I'd need a
brief "business justification".

..Stu

--
We make multiport serial boards.
<http://www.connecttech.com>
(800) 426-8979

Re: 3 Serial issues up for discussion

[Remco Treffkorn]

On Monday 29 July 2002 19:54, David S. Miller wrote:
>    From: Remco Treffkorn <remco@rvt.com>
>    Date: Mon, 29 Jul 2002 12:46:42 -0700
>
>    Drivers need not fight about minor numbers. That can be simply handled:
>
>    int get_new_serial_minor()
>    {
>        static int minor;
>
>        return minor++;
>    }
>
>    Any serial driver can call this when it initializes a new uart.
>    Hot pluggable drivers have to hang on to their minors, and
>    re-use.
>
> I don't think it's wise to make hot-plug drivers keep track
> of the minors they ever use in such a sloppy way.  Why not
> make the get_new_serial_minor() thing have a release method
> too and then we can keep track of minor allocation in one
> place.
>
> Also if I remmove the module for a serial port driver, those minors
> should get reused by the next registered uart too.

Point taken.
Here are a few more points.

The given solution presents almost zero overhead, but has the mentioned 
problem. There is a way to allocate and free minor numbers, but that requires 
storage. It could be handled like the fd_set's select uses. Just a bit field. 
Bit cleared == minor available, bit set == in use.

If you want to do that, you would want to know the maximum number of minors 
used. Also, finding the first cleared bit in your field costs more on some 
platforms, than on others.

Although I suspect this additional overhead to not matter much, since 
initialising a new uart is a rare event, I have bin surprised in the past.

So:
How many minors?
Is the overhead in getting a minor acceptable?
Is it worth doing?

Cheers,
Remco

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco@rvt.com   (831) 685-1201

Re: 3 Serial issues up for discussion

[Nicolas Pitre]

On Mon, 29 Jul 2002, David S. Miller wrote:

> Finally we can name this all /dev/serialXXX in keeping with Linus's
> grand view of /dev/diskXXX et al. (and keeping ttySfoo around for
> compat sake for a little while of course :).

Amen!


Nicolas

Re: 3 Serial issues up for discussion

[Nicolas Pitre]

On Tue, 30 Jul 2002, Remco Treffkorn wrote:

> Is the overhead in getting a minor acceptable?

Come on!  Is actually getting a minor for your serial ports, which only 
happens at registration time, a really big bottleneck on your system?


Nicolas

Re: 3 Serial issues up for discussion

[Russell King]

On Tue, Jul 30, 2002 at 11:23:47AM -0700, Remco Treffkorn wrote:
> The given solution presents almost zero overhead, but has the mentioned 
> problem. There is a way to allocate and free minor numbers, but that requires 
> storage. It could be handled like the fd_set's select uses. Just a bit field. 
> Bit cleared == minor available, bit set == in use.

core.c already knows which "slots" are in use and which aren't, so
allocation and freeing of minor numbers isn't that much of a problem.

The sole purpose behind this is to solicit is peoples opinions and
ideas on those three points I've raised.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [parisc-linux] 3 Serial issues up for discussion (was: Re: Serial core problems on embedded PPC)

[Jeff Randall]

On Mon, Jul 29, 2002 at 11:19:27PM +0100, Matthew Wilcox wrote:
> I'm not.  All the issues you mention below go away if we make the rule
> that _all_ serial ports are /dev/ttyS*.  Userspace can have symlinks to
> ease the transition if necessary.

Might I suggest that each driver then have a character code after the
ttyS before the numbering starts?  Then each driver could sanely number
its own devices and not worry about confict with another driver.

Also, drivers that have the potential for large port counts might best
provide their own node creation methods instead of relying upon MAKEDEV
to know about all the nodes it might need at any given time.

The last driver I worked upon (the Digi dgdm driver) exported the nodes
it wanted made in /proc and the rc script that came with the driver built
them at each boot in accordance with the product that the driver detected.



> > c. People with many serial ports.  We _could_ change the device number
> >    allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc
> >    device numbers so we end up with the same number of port slots
> >    available for those with many many serial ports in their machines.
> 
> Yep, there really are people with >256 serial ports.  It'd be nice to
> support them.  Does anything care about the mapping from device name
> to char minor?  I suspect the MAKEDEV maintainer will come and squash
> me if i suggest moving the mapping for the first 192 serial devices,
> but we should be able to reclaim:
> 
> Chase serial card (major 17/18), the Cyclades (major 19/20), Digiboard
> (major 22/23), Stallion (major 24/25), Specialix (32/33), isdn4linux
> (43/44), Comtrol (46/47), SDL RISCom (48/49), Hayes (57/58), Computone
> (71/72), Specialix (75/76), PAM (78/79), Comtrol VS (105/106), ISI
> (112/113), Technology Concepts (148/149), Specialix RIO (154/155/156/157),
> Chase Research (164/165), ACM (166/167), Moxa (172/173), SmartIO
> (174/175), USB (188/189), Low-density misc serial ports (204/205),
> userspace (208/209) BlueTooth (216/217), A2232 (224/225) ... holy crap,
> that's a lot of char dev space ;-)  52 majors.. think what those must
> be worth on the open market ;-)

Last I heard when I was working at Digi on the Digiboard driver, they wanted
to pull that driver out of the kernel entirely and support it on their own
(and none of the other drivers Digi distributes currently default to 22/23,
they tend to start at 70 and use as many as 10 minors, depending on the 
port count).



> My only real objection (and it's a problem we have at the moment!) is
> that serial ports then become like ethernet interfaces.  Add or remove a
> card and everything changes number.  Somehow we already survive with this.
> I was very careful when adding a new SIIG 4-port serial card to my console
> server the other day to notice which card was first in PCI bus scan
> order and make sure all my existing machines were hooked up to that one.
> 
> The solution to this has to be to name devices by PCI bus ID, but this is
> an argument for an entirely different thread ;-)

Agreed... but you have to consider other busses as well and incorporate
them into the naming scheme -- SCSI, USB, and Ethernet spring immediately
to mind.

It's my opinion that most people can get along well enough if the devices
are at least named consistently from boot to boot, but it would be nice
to have something a bit more stable than that so that adding and removing
units didn't change the device names.

It's not that important when you only have a couple boards, but some of
the drivers I worked on supported as many as 1024 units over ethernet..
and another 8 SCSI busses worth locally.. having one unit inserted into
the middle changing the order of half or more of the units would really
be a bad thing with such an installation.

Digi tried to make most of their nodes in a sub directory (/dev/digi/dgdm
or /dev/digi/els for example) and then link just the ttyS* nodes back up
into /dev

For large device counts (the dgdm driver made 5 nodes per physical port),
that's a sane way to go about IMHO.



Jeff Randall
(note: I'm no longer at Digi, I speak for myself, etc)
-- 
randall@uph.com    "It's a big world and you can hit it with any airplane."
                                           -- Flying, August 2000, Page 90.