The problem with using a PCI serial card for the console is that, until
the PCI serial driver is loaded, output will be lost. The issue is that
PCI serial devices use a non-standard I/O port address and sometimes use
a non-standard crystal frequency. This patch gets around those problems
by allowing you to specify both I/O port address and crystal frequency on
the kernel command line. The serial console specification is enhanced to be:
BBBBPNF-III/CCC
where BBBB is the baud rate, P is the parity, N is the number of bits,
F is the flow control, III is the I/O port address (prefix with 0x for
hexadecimal) and CCC is the crystal frequency. -III and /CCC are optional
and can be omitted although -III must be specified if you want to set
/CCC. For example, the option I use is:
console=ttyS0,115200-0xe880/921600
Signed-off-by: Don Dugger <[email protected]>
Documentation/serial-console.txt | 12 ++++++++----
drivers/serial/8250.c | 2 +-
drivers/serial/serial_core.c | 26 ++++++++++++++++++++++----
include/linux/serial_core.h | 2 +-
4 files changed, 32 insertions(+), 10 deletions(-)
----- cut here for patch.d/pci_serial-1014.patch -----
diff --git a/Documentation/serial-console.txt b/Documentation/serial-console.txt
index 9a7bc8b..8cffce6 100644
--- a/Documentation/serial-console.txt
+++ b/Documentation/serial-console.txt
@@ -21,10 +21,14 @@ The format of this option is:
options: depend on the driver. For the serial port this
defines the baudrate/parity/bits/flow control of
- the port, in the format BBBBPNF, where BBBB is the
- speed, P is parity (n/o/e), N is number of bits,
- and F is flow control ('r' for RTS). Default is
- 9600n8. The maximum baudrate is 115200.
+ the port, in the format BBBBPNF-III/CCC, where BBBB
+ is the speed, P is parity (n/o/e), N is number of bits,
+ F is flow control ('r' for RTS), III is I/O port
+ address (prefix with 0x for hexadecimal) and CCC is
+ the uart crystal frequency. Default is 9600n8. The
+ I/O port defaults to 0x3f8 for ttyS0 and 0x2f8 for
+ ttyS1. The default crystal frequency is 1843200.
+ The maximum baudrate is 115200.
You can specify multiple console= options on the kernel command line.
Output will appear on all of them. The last device will be used when
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index d3ca7d3..5d59cf7 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2632,7 +2632,7 @@ static int __init serial8250_console_setup(struct console *co, char *options)
return -ENODEV;
if (options)
- uart_parse_options(options, &baud, &parity, &bits, &flow);
+ uart_parse_options(options, &baud, &parity, &bits, &flow, &port->iobase, &port->uartclk);
return uart_set_options(port, co, baud, parity, bits, flow);
}
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index 6bdf336..31b5545 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1864,25 +1864,43 @@ uart_get_console(struct uart_port *ports, int nr, struct console *co)
* @parity: pointer to an 'int' variable for the parity.
* @bits: pointer to an 'int' variable for the number of data bits.
* @flow: pointer to an 'int' variable for the flow control character.
+ * @ioport: pointer to an 'int' variable for the I/O base for device
+ * @clk: pointer to an 'int' variable for the clock devisor
*
* uart_parse_options decodes a string containing the serial console
* options. The format of the string is <baud><parity><bits><flow>,
* eg: 115200n8r
*/
void
-uart_parse_options(char *options, int *baud, int *parity, int *bits, int *flow)
+uart_parse_options(char *options, int *baud, int *parity, int *bits, int *flow, int *ioport, int *clk)
{
char *s = options;
*baud = simple_strtoul(s, NULL, 10);
while (*s >= '0' && *s <= '9')
s++;
- if (*s)
+ if (*s && (*s != '-'))
*parity = *s++;
- if (*s)
+ if (*s && (*s != '-'))
*bits = *s++ - '0';
- if (*s)
+ if (*s && (*s != '-'))
*flow = *s;
+ if (*s && (*s != '-'))
+ *flow = *s++;
+ if (*s++ == '-') {
+ int b;
+
+ if (*s == '0' && (*(s + 1) == 'x' || *(s + 1) == 'X')) {
+ s += 2;
+ b = 16;
+ } else
+ b = 10;
+ *ioport = simple_strtoul(s, NULL, b);
+ while (*s && (*s != '/'))
+ s++;
+ if (*s == '/')
+ *clk = simple_strtoul(s + 1, NULL, 10) << 4;
+ }
}
EXPORT_SYMBOL_GPL(uart_parse_options);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index e27f216..3b4fb3a 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -402,7 +402,7 @@ unsigned int uart_get_divisor(struct uart_port *port, unsigned int baud);
struct uart_port *uart_get_console(struct uart_port *ports, int nr,
struct console *c);
void uart_parse_options(char *options, int *baud, int *parity, int *bits,
- int *flow);
+ int *flow, int *iobase, int *clk);
int uart_set_options(struct uart_port *port, struct console *co, int baud,
int parity, int bits, int flow);
struct tty_driver *uart_console_device(struct console *co, int *index);
On Tue, Oct 14, 2008 at 3:31 PM, <[email protected]> wrote:
> The problem with using a PCI serial card for the console is that, until
> the PCI serial driver is loaded, output will be lost. The issue is that
> PCI serial devices use a non-standard I/O port address and sometimes use
> a non-standard crystal frequency. This patch gets around those problems
> by allowing you to specify both I/O port address and crystal frequency on
> the kernel command line. The serial console specification is enhanced to be:
>
> BBBBPNF-III/CCC
>
> where BBBB is the baud rate, P is the parity, N is the number of bits,
> F is the flow control, III is the I/O port address (prefix with 0x for
> hexadecimal) and CCC is the crystal frequency. -III and /CCC are optional
> and can be omitted although -III must be specified if you want to set
> /CCC. For example, the option I use is:
>
> console=ttyS0,115200-0xe880/921600
Did you check
console=uart8250,io,0xe880,115200n8
hope you can expand that to support CCC
YH
> F is the flow control, III is the I/O port address (prefix with 0x for
> hexadecimal) and CCC is the crystal frequency. -III and /CCC are optional
> and can be omitted although -III must be specified if you want to set
> /CCC. For example, the option I use is:
I am sure real men would compute the equivalent baud rate for the clock by
hand ;) This looks a sensible patch, will queue.
Now I wonder if uart_parse_options can be __init
Alan
Alan-
Wait off a bit. YH pointed out that early printk (I should have checked
that) already has be ability to specify a I/O address. All I need to do
is enhance the early printk code to specify a clock frequency, I should
have that patch ready shortly.
I was kind of torn between specifying the frequency vs. the max baud rate
and went with the frequency on the off chance that some weird HW might
come out that needs a different multiplier. I figured anybody who needs
to specify the number can do the appropriate arithmetic.
On Tue, Oct 14, 2008 at 11:53:17PM +0100, Alan Cox wrote:
> > F is the flow control, III is the I/O port address (prefix with 0x for
> > hexadecimal) and CCC is the crystal frequency. -III and /CCC are optional
> > and can be omitted although -III must be specified if you want to set
> > /CCC. For example, the option I use is:
>
> I am sure real men would compute the equivalent baud rate for the clock by
> hand ;) This looks a sensible patch, will queue.
>
> Now I wonder if uart_parse_options can be __init
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Tue, Oct 14, 2008 at 03:39:44PM -0700, Yinghai Lu wrote:
> ...
> Did you check
>
> console=uart8250,io,0xe880,115200n8
>
> hope you can expand that to support CCC
>
> YH
Good suggestion. Here is a much simpler patch that just expands
the early printk to add a clock frequency parameter, e.g. I use:
console=uart8250,io,0xe880,115200,921600
Signed-off-by: Don Dugger <[email protected]>
Documentation/kernel-parameters.txt | 9 ++++++---
drivers/serial/8250_early.c | 5 +++++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 2443f5b..95ab44f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -505,12 +505,15 @@ and is between 256 and 4096 characters. It is defined in the file
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options[,clk]]
+ uart[8250],mmio,<addr>[,options[,clk]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ "options" are the same as for ttyS, above. "clk"
+ is the crystal frequency which defaults to 1843200
+ (115200 * 16) but some hardware uses different
+ crystal.
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
index f279745..edd5803 100644
--- a/drivers/serial/8250_early.c
+++ b/drivers/serial/8250_early.c
@@ -180,6 +180,11 @@ static int __init parse_options(struct early_serial8250_device *device,
snprintf(device->options, sizeof(device->options), "%u",
device->baud);
}
+ options = strchr(options, ',');
+ if (options) {
+ options++;
+ port->uartclk = simple_strtoul(options, NULL, 0) * 16;
+ }
printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",
On Tue, 2008-10-14 at 17:30 -0600, [email protected] wrote:
> - uart[8250],io,<addr>[,options]
> - uart[8250],mmio,<addr>[,options]
> + uart[8250],io,<addr>[,options[,clk]]
> + uart[8250],mmio,<addr>[,options[,clk]]
> Start an early, polled-mode console on the 8250/16550
> UART at the specified I/O port or MMIO address,
> switching to the matching ttyS device later. The
> - options are the same as for ttyS, above.
> + "options" are the same as for ttyS, above. "clk"
> + is the crystal frequency which defaults to 1843200
> + (115200 * 16) but some hardware uses different
> + crystal.
Shouldn't the earlycon entry be updated for the "clk" stuff too?
Paul Bolle
On Wed, Oct 15, 2008 at 11:13:19AM +0200, Paul Bolle wrote:
>...
> Shouldn't the earlycon entry be updated for the "clk" stuff too?
>
>
> Paul Bolle
Indeed, I missed that. Here is the final (?) version of the patch,
the only change is in the documentation.
As an aside, I would personally be in favor of removing the `earlycon'
kernel parameter entirely, it seems to be a strict subset of the
`console' parameter and anyone that wants `earlycon' probably wants
`console' anyway. Is there a strong argument for keeping that
parameter that I'm missing?
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
Documentation/kernel-parameters.txt | 13 ++++++++-----
drivers/serial/8250_early.c | 5 +++++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 2443f5b..bf6dd6f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -505,12 +505,15 @@ and is between 256 and 4096 characters. It is defined in the file
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options[,clk]]
+ uart[8250],mmio,<addr>[,options[,clk]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ "options" are the same as for ttyS, above. "clk"
+ is the crystal frequency which defaults to 115200
+ (typically the fastest baud rate supported by the
+ uart) but some hardware use different crystals.
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
@@ -518,8 +521,8 @@ and is between 256 and 4096 characters. It is defined in the file
For now, only VisioBraille is supported.
earlycon= [KNL] Output early console device and options.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options,[clkd]]
+ uart[8250],mmio,<addr>[,options,[clkd]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
The options are the same as for ttyS, above.
diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
index f279745..edd5803 100644
--- a/drivers/serial/8250_early.c
+++ b/drivers/serial/8250_early.c
@@ -180,6 +180,11 @@ static int __init parse_options(struct early_serial8250_device *device,
snprintf(device->options, sizeof(device->options), "%u",
device->baud);
}
+ options = strchr(options, ',');
+ if (options) {
+ options++;
+ port->uartclk = simple_strtoul(options, NULL, 0) * 16;
+ }
printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",
On Wed, 2008-10-15 at 14:48 -0600, [email protected] wrote:
> On Wed, Oct 15, 2008 at 11:13:19AM +0200, Paul Bolle wrote:
> As an aside, I would personally be in favor of removing the `earlycon'
> kernel parameter entirely, it seems to be a strict subset of the
> `console' parameter and anyone that wants `earlycon' probably wants
> `console' anyway. Is there a strong argument for keeping that
> parameter that I'm missing?
The same thing puzzles me too. Note that earlyprintk=serial|ttyS?[...]
also provides a similar feature.
> earlycon= [KNL] Output early console device and options.
>- uart[8250],io,<addr>[,options]
>- uart[8250],mmio,<addr>[,options]
>+ uart[8250],io,<addr>[,options,[clkd]]
>+ uart[8250],mmio,<addr>[,options,[clkd]]
clkd?
Paul Bolle
Paul Bolle wrote:
> On Wed, 2008-10-15 at 14:48 -0600, [email protected] wrote:
>> On Wed, Oct 15, 2008 at 11:13:19AM +0200, Paul Bolle wrote:
>> As an aside, I would personally be in favor of removing the `earlycon'
>> kernel parameter entirely, it seems to be a strict subset of the
>> `console' parameter and anyone that wants `earlycon' probably wants
>> `console' anyway. Is there a strong argument for keeping that
>> parameter that I'm missing?
>
> The same thing puzzles me too. Note that earlyprintk=serial|ttyS?[...]
> also provides a similar feature.
>
>> earlycon= [KNL] Output early console device and options.
>> - uart[8250],io,<addr>[,options]
>> - uart[8250],mmio,<addr>[,options]
>> + uart[8250],io,<addr>[,options,[clkd]]
>> + uart[8250],mmio,<addr>[,options,[clkd]]
>
> clkd?
earlycon= and conole= share uart[8250]...
the difference console= will start from early console and switch normal console automatically if the ttyS come out with same io/mmio address etc.
YH
On Thu, Oct 16, 2008 at 09:23:39AM -0700, Yinghai Lu wrote:
>...
> earlycon= and conole= share uart[8250]...
>
> the difference console= will start from early console and switch normal console automatically if the ttyS come out with same io/mmio address etc.
>
But there is no advantage to `earlycon' given that you can accomplish
the same thing with `console'. The only use that I can see is if
you specify `earlycon' without specifying `console' and then all
you get are the initial kernel messages, after the serial drivers
intializes all further messages go to the VGA. If makes much more
sense to me to just use the `console' parameter to get all kernel
messages on the serial port, and then there is no need for
`earlycon'.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
[email protected] wrote:
> On Thu, Oct 16, 2008 at 09:23:39AM -0700, Yinghai Lu wrote:
>> ...
>> earlycon= and conole= share uart[8250]...
>>
>> the difference console= will start from early console and switch normal console automatically if the ttyS come out with same io/mmio address etc.
>>
>
> But there is no advantage to `earlycon' given that you can accomplish
> the same thing with `console'. The only use that I can see is if
> you specify `earlycon' without specifying `console' and then all
> you get are the initial kernel messages, after the serial drivers
> intializes all further messages go to the VGA. If makes much more
> sense to me to just use the `console' parameter to get all kernel
> messages on the serial port, and then there is no need for
> `earlycon'.
>
/* Check for early params. */
static int __init do_early_param(char *param, char *val)
{
struct obs_kernel_param *p;
for (p = __setup_start; p < __setup_end; p++) {
if ((p->early && strcmp(param, p->str) == 0) ||
(strcmp(param, "console") == 0 &&
strcmp(p->str, "earlycon") == 0)
) {
if (p->setup_func(val) != 0)
printk(KERN_WARNING
"Malformed early option '%s'\n", param);
}
}
/* We accept everything at this stage. */
return 0;
}
we need that holder in console sections to compare with console and earlycon.
YH
On Thu, Oct 16, 2008 at 11:19:28AM -0700, Yinghai Lu wrote:
>...
> if ((p->early && strcmp(param, p->str) == 0) ||
> (strcmp(param, "console") == 0 &&
> strcmp(p->str, "earlycon") == 0)
>...
> we need that holder in console sections to compare with console and earlycon.
>
I have no problem with keeping the code associated with early
prints, as you say we need that holder. I'm saying the `console'
parameter serves this purpose, we only need to remove the `earlycon'
portion of that if statement.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Thu, Oct 16, 2008 at 11:25 AM, <[email protected]> wrote:
> On Thu, Oct 16, 2008 at 11:19:28AM -0700, Yinghai Lu wrote:
>>...
>> if ((p->early && strcmp(param, p->str) == 0) ||
>> (strcmp(param, "console") == 0 &&
>> strcmp(p->str, "earlycon") == 0)
>>...
>> we need that holder in console sections to compare with console and earlycon.
>>
>
> I have no problem with keeping the code associated with early
> prints, as you say we need that holder. I'm saying the `console'
> parameter serves this purpose, we only need to remove the `earlycon'
> portion of that if statement.
but if someone don't need the switch from early console to normal console...
YH
On Thu, Oct 16, 2008 at 11:30:17AM -0700, Yinghai Lu wrote:
>...
> but if someone don't need the switch from early console to normal console...
>
Back to my original point, why would someone want just the
early console output on serial but not want the normal console
on serial? I can't think of any use case where this makes
sense.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Tuesday 14 October 2008 04:31:09 pm [email protected] wrote:
> The problem with using a PCI serial card for the console is that, until
> the PCI serial driver is loaded, output will be lost. The issue is that
> PCI serial devices use a non-standard I/O port address and sometimes use
> a non-standard crystal frequency. This patch gets around those problems
> by allowing you to specify both I/O port address and crystal frequency on
> the kernel command line. The serial console specification is enhanced to be:
>
> BBBBPNF-III/CCC
>
> where BBBB is the baud rate, P is the parity, N is the number of bits,
> F is the flow control, III is the I/O port address (prefix with 0x for
> hexadecimal) and CCC is the crystal frequency. -III and /CCC are optional
> and can be omitted although -III must be specified if you want to set
> /CCC. For example, the option I use is:
>
> console=ttyS0,115200-0xe880/921600
Did you play with "console=uart,io,0xe880,115200n8" at all?
That gives you early serial console output and automatically switches
to the matching ttyS device when it is discovered.
"console=uart" doesn't have support for crystal frequency, but that
could be added in drivers/serial/8250_early.c.
I think that's a better approach because if the command line
contains both the ttyS name and the I/O port address, we have
to worry about what to do when they don't match, e.g., what happens
if the device at 0xe880 turns out to be ttyS1 instead of ttyS0?
Bjorn
> Signed-off-by: Don Dugger <[email protected]>
>
> Documentation/serial-console.txt | 12 ++++++++----
> drivers/serial/8250.c | 2 +-
> drivers/serial/serial_core.c | 26 ++++++++++++++++++++++----
> include/linux/serial_core.h | 2 +-
> 4 files changed, 32 insertions(+), 10 deletions(-)
>
>
> ----- cut here for patch.d/pci_serial-1014.patch -----
> diff --git a/Documentation/serial-console.txt b/Documentation/serial-console.txt
> index 9a7bc8b..8cffce6 100644
> --- a/Documentation/serial-console.txt
> +++ b/Documentation/serial-console.txt
> @@ -21,10 +21,14 @@ The format of this option is:
>
> options: depend on the driver. For the serial port this
> defines the baudrate/parity/bits/flow control of
> - the port, in the format BBBBPNF, where BBBB is the
> - speed, P is parity (n/o/e), N is number of bits,
> - and F is flow control ('r' for RTS). Default is
> - 9600n8. The maximum baudrate is 115200.
> + the port, in the format BBBBPNF-III/CCC, where BBBB
> + is the speed, P is parity (n/o/e), N is number of bits,
> + F is flow control ('r' for RTS), III is I/O port
> + address (prefix with 0x for hexadecimal) and CCC is
> + the uart crystal frequency. Default is 9600n8. The
> + I/O port defaults to 0x3f8 for ttyS0 and 0x2f8 for
> + ttyS1. The default crystal frequency is 1843200.
> + The maximum baudrate is 115200.
>
> You can specify multiple console= options on the kernel command line.
> Output will appear on all of them. The last device will be used when
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index d3ca7d3..5d59cf7 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -2632,7 +2632,7 @@ static int __init serial8250_console_setup(struct console *co, char *options)
> return -ENODEV;
>
> if (options)
> - uart_parse_options(options, &baud, &parity, &bits, &flow);
> + uart_parse_options(options, &baud, &parity, &bits, &flow, &port->iobase, &port->uartclk);
>
> return uart_set_options(port, co, baud, parity, bits, flow);
> }
> diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
> index 6bdf336..31b5545 100644
> --- a/drivers/serial/serial_core.c
> +++ b/drivers/serial/serial_core.c
> @@ -1864,25 +1864,43 @@ uart_get_console(struct uart_port *ports, int nr, struct console *co)
> * @parity: pointer to an 'int' variable for the parity.
> * @bits: pointer to an 'int' variable for the number of data bits.
> * @flow: pointer to an 'int' variable for the flow control character.
> + * @ioport: pointer to an 'int' variable for the I/O base for device
> + * @clk: pointer to an 'int' variable for the clock devisor
> *
> * uart_parse_options decodes a string containing the serial console
> * options. The format of the string is <baud><parity><bits><flow>,
> * eg: 115200n8r
> */
> void
> -uart_parse_options(char *options, int *baud, int *parity, int *bits, int *flow)
> +uart_parse_options(char *options, int *baud, int *parity, int *bits, int *flow, int *ioport, int *clk)
> {
> char *s = options;
>
> *baud = simple_strtoul(s, NULL, 10);
> while (*s >= '0' && *s <= '9')
> s++;
> - if (*s)
> + if (*s && (*s != '-'))
> *parity = *s++;
> - if (*s)
> + if (*s && (*s != '-'))
> *bits = *s++ - '0';
> - if (*s)
> + if (*s && (*s != '-'))
> *flow = *s;
> + if (*s && (*s != '-'))
> + *flow = *s++;
> + if (*s++ == '-') {
> + int b;
> +
> + if (*s == '0' && (*(s + 1) == 'x' || *(s + 1) == 'X')) {
> + s += 2;
> + b = 16;
> + } else
> + b = 10;
> + *ioport = simple_strtoul(s, NULL, b);
> + while (*s && (*s != '/'))
> + s++;
> + if (*s == '/')
> + *clk = simple_strtoul(s + 1, NULL, 10) << 4;
> + }
> }
> EXPORT_SYMBOL_GPL(uart_parse_options);
>
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index e27f216..3b4fb3a 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -402,7 +402,7 @@ unsigned int uart_get_divisor(struct uart_port *port, unsigned int baud);
> struct uart_port *uart_get_console(struct uart_port *ports, int nr,
> struct console *c);
> void uart_parse_options(char *options, int *baud, int *parity, int *bits,
> - int *flow);
> + int *flow, int *iobase, int *clk);
> int uart_set_options(struct uart_port *port, struct console *co, int baud,
> int parity, int bits, int flow);
> struct tty_driver *uart_console_device(struct console *co, int *index);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, Oct 16, 2008 at 05:16:47PM -0600, Bjorn Helgaas wrote:
>...
> Did you play with "console=uart,io,0xe880,115200n8" at all?
>
> That gives you early serial console output and automatically switches
> to the matching ttyS device when it is discovered.
>
> "console=uart" doesn't have support for crystal frequency, but that
> could be added in drivers/serial/8250_early.c.
>
Yep, that was pointed out and my latest patch does just that, use the
`uart' syntax to specify I/O address and enhance it to control crystal
frequency.
We're arguing now about what to do about the `earlycon' and `earlyprintk'
parameters, I contend we should remove those as the `console=uart' is
a superset of their capabilities but there are some dissenting opinions.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Thu, Oct 16, 2008 at 11:30:17AM -0700, Yinghai Lu wrote:
>...
> but if someone don't need the switch from early console to normal console...
>
When would that ever be useful? I can understand wanting early printks
and normal console printks going to the serial device. I can understand
wanting neither to go to serial. I just don't see why you would ever
want the early printks to go to serial and then stop using the serial
for normal console printks, that just doesn't make sense.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Thu, Oct 16, 2008 at 7:45 PM, <[email protected]> wrote:
> On Thu, Oct 16, 2008 at 11:30:17AM -0700, Yinghai Lu wrote:
>>...
>> but if someone don't need the switch from early console to normal console...
>>
>
> When would that ever be useful? I can understand wanting early printks
> and normal console printks going to the serial device. I can understand
> wanting neither to go to serial. I just don't see why you would ever
> want the early printks to go to serial and then stop using the serial
> for normal console printks, that just doesn't make sense.
you want to remove earlycon from Documenatation/kernel-parameters.txt?
YH
> We're arguing now about what to do about the `earlycon' and `earlyprintk'
> parameters, I contend we should remove those as the `console=uart' is
> a superset of their capabilities but there are some dissenting opinions.
Different discussion and different patches. We can get patches in for the
crystal frequency stuff and then debate the rest later
On Fri, Oct 17, 2008 at 10:28:58AM +0100, Alan Cox wrote:
> Different discussion and different patches. We can get patches in for the
> crystal frequency stuff and then debate the rest later
In that case, here is the crystal frequency patch (typos fixed and
proper sign off line).
Signed-off-by: Don Dugger <[email protected]>
Documentation/kernel-parameters.txt | 13 ++++++++-----
drivers/serial/8250_early.c | 5 +++++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 2443f5b..bf6dd6f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -505,12 +505,15 @@ and is between 256 and 4096 characters. It is defined in the file
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options[,clk]]
+ uart[8250],mmio,<addr>[,options[,clk]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ "options" are the same as for ttyS, above. "clk"
+ is the crystal frequency which defaults to 115200
+ (typically the fastest baud rate supported by the
+ uart) but some hardware use different crystals.
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
@@ -518,8 +521,8 @@ and is between 256 and 4096 characters. It is defined in the file
For now, only VisioBraille is supported.
earlycon= [KNL] Output early console device and options.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options,[clk]]
+ uart[8250],mmio,<addr>[,options,[clk]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
The options are the same as for ttyS, above.
diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
index f279745..edd5803 100644
--- a/drivers/serial/8250_early.c
+++ b/drivers/serial/8250_early.c
@@ -180,6 +180,11 @@ static int __init parse_options(struct early_serial8250_device *device,
snprintf(device->options, sizeof(device->options), "%u",
device->baud);
}
+ options = strchr(options, ',');
+ if (options) {
+ options++;
+ port->uartclk = simple_strtoul(options, NULL, 0) * 16;
+ }
printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",
On Thursday 16 October 2008 08:39:12 pm [email protected] wrote:
> On Thu, Oct 16, 2008 at 05:16:47PM -0600, Bjorn Helgaas wrote:
> >...
> > Did you play with "console=uart,io,0xe880,115200n8" at all?
> >
> > That gives you early serial console output and automatically switches
> > to the matching ttyS device when it is discovered.
> >
> > "console=uart" doesn't have support for crystal frequency, but that
> > could be added in drivers/serial/8250_early.c.
> >
>
> Yep, that was pointed out and my latest patch does just that, use the
> `uart' syntax to specify I/O address and enhance it to control crystal
> frequency.
Oops, sorry, I forgot to read the followups before responding.
On Friday 17 October 2008 08:11:02 am [email protected] wrote:
> On Fri, Oct 17, 2008 at 10:28:58AM +0100, Alan Cox wrote:
> > Different discussion and different patches. We can get patches in for the
> > crystal frequency stuff and then debate the rest later
>
> In that case, here is the crystal frequency patch (typos fixed and
> proper sign off line).
I like this patch, except ...
> + "options" are the same as for ttyS, above. "clk"
> + is the crystal frequency which defaults to 115200
> + (typically the fastest baud rate supported by the
> + uart) but some hardware use different crystals.
this text is a little confusing. Since you multiply by 16 below, the
number specified by the user isn't really the crystal frequency, is it?
> + options = strchr(options, ',');
> + if (options) {
> + options++;
> + port->uartclk = simple_strtoul(options, NULL, 0) * 16;
> + }
On Fri, Oct 17, 2008 at 08:46:40AM -0600, Bjorn Helgaas wrote:
>...
> this text is a little confusing. Since you multiply by 16 below, the
> number specified by the user isn't really the crystal frequency, is it?
Can't argue with that. How about this patch which describes the
parameter more acurately as a multiplier.
Signed-off-by: Don Dugger <[email protected]>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 82c561f..6e5334d 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -505,12 +505,15 @@ and is between 256 and 4096 characters. It is defined in the file
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options[,mult]]
+ uart[8250],mmio,<addr>[,options[,mult]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ "options" are the same as for ttyS, above. "mult"
+ is a multiplier defining the crystal frequency which
+ defaults to 115200 (typically the fastest baud rate
+ supported by the uart).
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
@@ -518,8 +521,8 @@ and is between 256 and 4096 characters. It is defined in the file
For now, only VisioBraille is supported.
earlycon= [KNL] Output early console device and options.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options,[mult]]
+ uart[8250],mmio,<addr>[,options,[mult]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
The options are the same as for ttyS, above.
diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
index f279745..edd5803 100644
--- a/drivers/serial/8250_early.c
+++ b/drivers/serial/8250_early.c
@@ -180,6 +180,11 @@ static int __init parse_options(struct early_serial8250_device *device,
snprintf(device->options, sizeof(device->options), "%u",
device->baud);
}
+ options = strchr(options, ',');
+ if (options) {
+ options++;
+ port->uartclk = simple_strtoul(options, NULL, 0) * 16;
+ }
printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",
On Thu, Oct 16, 2008 at 08:32:53PM -0700, Yinghai Lu wrote:
>...
> you want to remove earlycon from Documenatation/kernel-parameters.txt?
>
> YH
I want to remove the documentation and also remove the code
associated with the earlycon `parameter`. I absolutely want
to keep the early printk capability but that should be
controlled by the `console' parameter, there's no need for
a separate `earlycon' parameter.
I am against code bloat and putting extra code in the kernel
to support unneeded parameters is just a waste.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Friday 17 October 2008 09:36:52 am [email protected] wrote:
> On Fri, Oct 17, 2008 at 08:46:40AM -0600, Bjorn Helgaas wrote:
> >...
> > this text is a little confusing. Since you multiply by 16 below, the
> > number specified by the user isn't really the crystal frequency, is it?
>
> Can't argue with that. How about this patch which describes the
> parameter more acurately as a multiplier.
Here's another possibility, maybe too wordy, but maybe more straightforward:
+ uart[8250],mmio,<addr>[,options[,clock]]
+ "clock" is the frequency of the crystal driving
+ the UART clock (typically sixteen times the
+ fastest baud rate supported by the UART).
+ port->uartclk = simple_strtoul(options, NULL, 0);
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 82c561f..6e5334d 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -505,12 +505,15 @@ and is between 256 and 4096 characters. It is defined in the file
> Documentation/networking/netconsole.txt for an
> alternative.
>
> - uart[8250],io,<addr>[,options]
> - uart[8250],mmio,<addr>[,options]
> + uart[8250],io,<addr>[,options[,mult]]
> + uart[8250],mmio,<addr>[,options[,mult]]
> Start an early, polled-mode console on the 8250/16550
> UART at the specified I/O port or MMIO address,
> switching to the matching ttyS device later. The
> - options are the same as for ttyS, above.
> + "options" are the same as for ttyS, above. "mult"
> + is a multiplier defining the crystal frequency which
> + defaults to 115200 (typically the fastest baud rate
> + supported by the uart).
>
> If the device connected to the port is not a TTY but a braille
> device, prepend "brl," before the device type, for instance
> @@ -518,8 +521,8 @@ and is between 256 and 4096 characters. It is defined in the file
> For now, only VisioBraille is supported.
>
> earlycon= [KNL] Output early console device and options.
> - uart[8250],io,<addr>[,options]
> - uart[8250],mmio,<addr>[,options]
> + uart[8250],io,<addr>[,options,[mult]]
> + uart[8250],mmio,<addr>[,options,[mult]]
> Start an early, polled-mode console on the 8250/16550
> UART at the specified I/O port or MMIO address.
> The options are the same as for ttyS, above.
> diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
> index f279745..edd5803 100644
> --- a/drivers/serial/8250_early.c
> +++ b/drivers/serial/8250_early.c
> @@ -180,6 +180,11 @@ static int __init parse_options(struct early_serial8250_device *device,
> snprintf(device->options, sizeof(device->options), "%u",
> device->baud);
> }
> + options = strchr(options, ',');
> + if (options) {
> + options++;
> + port->uartclk = simple_strtoul(options, NULL, 0) * 16;
> + }
>
> printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
> mmio ? "MMIO" : "I/O port",
>
[email protected] wrote:
> On Thu, Oct 16, 2008 at 08:32:53PM -0700, Yinghai Lu wrote:
>> ...
>> you want to remove earlycon from Documenatation/kernel-parameters.txt?
>>
>> YH
>
> I want to remove the documentation and also remove the code
> associated with the earlycon `parameter`. I absolutely want
> to keep the early printk capability but that should be
> controlled by the `console' parameter, there's no need for
> a separate `earlycon' parameter.
>
you can not remove the code, we need that holder in console section to call code init console.
and you don't need to remove earlycon in doc.
YH
On Fri, Oct 17, 2008 at 10:39:52AM -0600, Bjorn Helgaas wrote:
>...
> Here's another possibility, maybe too wordy, but maybe more straightforward:
>
> + uart[8250],mmio,<addr>[,options[,clock]]
>
> + "clock" is the frequency of the crystal driving
> + the UART clock (typically sixteen times the
> + fastest baud rate supported by the UART).
>
> + port->uartclk = simple_strtoul(options, NULL, 0);
>
We could do that but now the `clock' value becomes a very large
number that is very magic. Putting in the highest baud rate seems
to make more sense than some magic number.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Fri, Oct 17, 2008 at 11:06:38AM -0600, [email protected] wrote:
> We could do that but now the `clock' value becomes a very large
> number that is very magic. Putting in the highest baud rate seems
> to make more sense than some magic number.
Yeah, and isn't that usually called the base_baud or something like
that?
--
Len Sorensen
On Monday 20 October 2008 10:44:04 am Lennart Sorensen wrote:
> On Fri, Oct 17, 2008 at 11:06:38AM -0600, [email protected] wrote:
> > We could do that but now the `clock' value becomes a very large
> > number that is very magic. Putting in the highest baud rate seems
> > to make more sense than some magic number.
>
> Yeah, and isn't that usually called the base_baud or something like
> that?
It doesn't bother me that the number is large. It's only a factor
of 16 bigger than the baud rate. It is sort of magic, but on the
other hand, the number is often printed on a part on the board, so
it's easy to determine, and fairly easy to document. If you've
lost the box with the marketing messages on it, I'd argue that it's
easier to determine the clock rate than the fastest baud rate.
To me it seems more confusing to specify two baud rates: the one
you want to use, and the fastest one the UART supports.
Bjorn "i want my bike shed *blue*" :-)
On Mon, Oct 20, 2008 at 11:11:07AM -0600, Bjorn Helgaas wrote:
>...
> It doesn't bother me that the number is large. It's only a factor
> of 16 bigger than the baud rate. It is sort of magic, but on the
> other hand, the number is often printed on a part on the board, so
> it's easy to determine, and fairly easy to document. If you've
> lost the box with the marketing messages on it, I'd argue that it's
> easier to determine the clock rate than the fastest baud rate.
>
> To me it seems more confusing to specify two baud rates: the one
> you want to use, and the fastest one the UART supports.
Well, how about consistency with the current serial driver. The
current driver uses base baud, as evidenced by this code from
`drivers/serial/8250_pci.c':
static struct pciserial_board pci_boards[] __devinitdata = {
[pbn_default] = {
.flags = FL_BASE0,
.num_ports = 1,
.base_baud = 115200,
.uart_offset = 8,
},
I think it's even more important to follow what the driver is
doing. (If I'd lost the bix I would get the PCI IDs and see
what the driver is doing for my unknown card :-)
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
On Monday 20 October 2008 11:43:51 am [email protected] wrote:
> On Mon, Oct 20, 2008 at 11:11:07AM -0600, Bjorn Helgaas wrote:
> >...
> > It doesn't bother me that the number is large. It's only a factor
> > of 16 bigger than the baud rate. It is sort of magic, but on the
> > other hand, the number is often printed on a part on the board, so
> > it's easy to determine, and fairly easy to document. If you've
> > lost the box with the marketing messages on it, I'd argue that it's
> > easier to determine the clock rate than the fastest baud rate.
> >
> > To me it seems more confusing to specify two baud rates: the one
> > you want to use, and the fastest one the UART supports.
>
> Well, how about consistency with the current serial driver. The
> current driver uses base baud, as evidenced by this code from
> `drivers/serial/8250_pci.c':
>
> static struct pciserial_board pci_boards[] __devinitdata = {
> [pbn_default] = {
> .flags = FL_BASE0,
> .num_ports = 1,
> .base_baud = 115200,
> .uart_offset = 8,
> },
>
> I think it's even more important to follow what the driver is
> doing. (If I'd lost the bix I would get the PCI IDs and see
> what the driver is doing for my unknown card :-)
Ideally we could put something in Documentation/kernel-parameters.txt
that's useful for people who can't or don't want to look at
the source.
Bjorn
On Mon, Oct 20, 2008 at 01:11:05PM -0600, Bjorn Helgaas wrote:
>...
> Ideally we could put something in Documentation/kernel-parameters.txt
> that's useful for people who can't or don't want to look at
> the source.
How about this. I've modified the doc slightly to indicate that the
magic number is the base baud used to calculate the divsor used against
the crystal frequency. This should be sufficient for most people and
the curious should now have enough info to research the matter further.
Signed-off-by: Don Dugger <[email protected]>
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
Documentation/kernel-parameters.txt | 14 +++++++++-----
drivers/serial/8250_early.c | 5 +++++
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 82c561f..f07e77c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -505,12 +505,16 @@ and is between 256 and 4096 characters. It is defined in the file
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options[,base]]
+ uart[8250],mmio,<addr>[,options[,base]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ "options" are the same as for ttyS, above. "base"
+ is base baud, defaults to 115200, which is used to
+ calculate the divisor for the crystal frequency
+ (typically this is the fastest baud rate supported
+ by the uart).
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
@@ -518,8 +522,8 @@ and is between 256 and 4096 characters. It is defined in the file
For now, only VisioBraille is supported.
earlycon= [KNL] Output early console device and options.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options,[base]]
+ uart[8250],mmio,<addr>[,options,[base]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
The options are the same as for ttyS, above.
diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
index f279745..edd5803 100644
--- a/drivers/serial/8250_early.c
+++ b/drivers/serial/8250_early.c
@@ -180,6 +180,11 @@ static int __init parse_options(struct early_serial8250_device *device,
snprintf(device->options, sizeof(device->options), "%u",
device->baud);
}
+ options = strchr(options, ',');
+ if (options) {
+ options++;
+ port->uartclk = simple_strtoul(options, NULL, 0) * 16;
+ }
printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",
On Tuesday 21 October 2008 02:08:41 pm [email protected] wrote:
> ????????????????????????Start an early, polled-mode console on the 8250/16550
> ????????????????????????UART at the specified I/O port or MMIO address,
> ????????????????????????switching to the matching ttyS device later. ?The
> -???????????????????????options are the same as for ttyS, above.
> +???????????????????????"options" are the same as for ttyS, above. ?"base"
> +???????????????????????is base baud, defaults to 115200, which is used to
> +???????????????????????calculate the divisor for the crystal frequency
> +???????????????????????(typically this is the fastest baud rate supported
> +???????????????????????by the uart).
>
Down to nits now :-) That last sentence would be clearer to me if it
said '(typically "base" is the fastest baud rate supported by the UART).'
I capitalized UART to match the one earlier.
Bjorn
On Tue, Oct 21, 2008 at 04:08:03PM -0600, Bjorn Helgaas wrote:
>...
> Down to nits now :-) That last sentence would be clearer to me if it
> said '(typically "base" is the fastest baud rate supported by the UART).'
> I capitalized UART to match the one earlier.
NP, consistency is a good thing.
Signed-off-by: Don Dugger <[email protected]>
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/443-3786
Documentation/kernel-parameters.txt | 14 +++++++++-----
drivers/serial/8250_early.c | 5 +++++
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 82c561f..f07e77c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -505,12 +505,16 @@ and is between 256 and 4096 characters. It is defined in the file
Documentation/networking/netconsole.txt for an
alternative.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options[,base]]
+ uart[8250],mmio,<addr>[,options[,base]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
- options are the same as for ttyS, above.
+ "options" are the same as for ttyS, above. "base"
+ is base baud, defaults to 115200, which is used to
+ calculate the divisor for the crystal frequency
+ (typically "base" is the fastest baud rate supported
+ by the UART).
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
@@ -518,8 +522,8 @@ and is between 256 and 4096 characters. It is defined in the file
For now, only VisioBraille is supported.
earlycon= [KNL] Output early console device and options.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
+ uart[8250],io,<addr>[,options,[base]]
+ uart[8250],mmio,<addr>[,options,[base]]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
The options are the same as for ttyS, above.
diff --git a/drivers/serial/8250_early.c b/drivers/serial/8250_early.c
index f279745..edd5803 100644
--- a/drivers/serial/8250_early.c
+++ b/drivers/serial/8250_early.c
@@ -180,6 +180,11 @@ static int __init parse_options(struct early_serial8250_device *device,
snprintf(device->options, sizeof(device->options), "%u",
device->baud);
}
+ options = strchr(options, ',');
+ if (options) {
+ options++;
+ port->uartclk = simple_strtoul(options, NULL, 0) * 16;
+ }
printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",