From: Russell King <hidden> Date: 2002-07-29 17:13:44
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:
quoted
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
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/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Christoph Plattner <hidden> Date: 2002-07-29 17:44:43
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:
quoted
On Mon, Jul 29, 2002 at 10:00:10AM +0100, Russell King wrote:
quoted
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
_______________________________________________
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2002-07-29 18:50:30
quoted
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.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Jul 29, 2002 at 08:13:52PM +0200, Benjamin Herrenschmidt wrote:
quoted
quoted
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/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-07-29 19:07:43
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: David S. Miller <hidden> Date: 2002-07-30 02:59:56
From: Russell King [off-list ref]
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.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: David S. Miller <hidden> Date: 2002-07-30 03:02:33
From: Remco Treffkorn [off-list ref]
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 :).
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/