public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: serial legacy ports and ACPI
Date: Tue, 26 Aug 2003 16:24:43 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106191580620525@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105761215001812@msgid-missing>

Jes Sorensen wrote:
> 
> I had a chat with Grant and Matthew about is a little while ago (and
> possibly a few other people whom I can't remember right now) and we
> basically came to a similar conclusion. Once I find a bit more time,
> I'd like to introduce an interface along the lines of
> 
>         legacy_device_present(LEGACY_{IDE,SERIAL,PARALLEL})
> 
> This could be quite useful for other architectures as well I believe.

Jes,

   Digging up an old topic.  I started looking at this from a serial
port numbering perspective and came up with a fairly simple way for
the architecure code to handle it on it's own.  Here's my idea vs
2.6:

--- linux/arch/ia64/kernel/acpi.c
+++ linux/arch/ia64/kernel/acpi.c
@@ -41,6 +41,9 @@
 #include <linux/irq.h>
 #include <linux/acpi.h>
 #include <linux/efi.h>
+#include <linux/tty.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
 #include <asm/io.h>
 #include <asm/iosapic.h>
 #include <asm/machvec.h>
@@ -530,6 +533,20 @@
        if (!(fadt->iapc_boot_arch & BAF_8042_KEYBOARD_CONTROLLER))
                acpi_kbd_controller_present = 0;
 
+#ifdef CONFIG_SERIAL_8250
+       if (!(fadt->iapc_boot_arch & BAF_LEGACY_DEVICES)) {
+               int i;
+               struct uart_port port;
+
+               memset(&port, 0, sizeof(port));
+
+               for (i = 0 ; i < 4 ; i++) {
+                       port.line = i;
+                       early_serial_setup(&port);
+               }
+       }
+#endif
+
        acpi_register_irq(fadt->sci_int, ACPI_ACTIVE_LOW, ACPI_LEVEL_SENSITIVE);
        return 0;
 }

   This example only hits the first 4 ports, but we could clear the whole
table if we decide that's the right thing to do.  Does anybody really
use EXTRA_SERIAL_PORT_DEFNS and HUB6_SERIAL_PORT_DFNS or should those
be considered "legacy" as well?  The serial port part of this problem
kind of feels like an architecture problem since we start out passing
in a table of serial ports to probe.  Thoughts?

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab

      parent reply	other threads:[~2003-08-26 16:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-07 21:05 serial legacy ports and ACPI Jes Sorensen
2003-07-30 23:09 ` Bjorn Helgaas
2003-07-31  3:54 ` Jes Sorensen
2003-08-26 16:24 ` Alex Williamson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ia64-106191580620525@msgid-missing \
    --to=alex.williamson@hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox