linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Going beyond 256 PCI buses
Date: Thu, 14 Jun 2001 15:49:48 -0700 (PDT)	[thread overview]
Message-ID: <15145.16268.239882.904451@pizda.ninka.net> (raw)
In-Reply-To: <20010614222901.13715@smtp.wanadoo.fr>
In-Reply-To: <15145.14057.67940.752173@pizda.ninka.net> <20010614222901.13715@smtp.wanadoo.fr>


Benjamin Herrenschmidt writes:
 > Well... that would work for VGA itself (note that this semaphore
 > you are talking about should be shared some way with the /proc
 > interface so XFree can be properly sync'ed as well).

Once XFree takes ownership of the VC it has control of all the
graphics cards in the system.  It does this before it does any poking
around.

 > But I still think it may be useful to generalize the idea to 
 > all kind of legacy IO & PIOs. I definitely agree that VGA is a kind
 > of special case, mostly because of the necessary exclusion on
 > the VGA IO response.

I don't think this is the way to go.

First, what would you use it for?  Let's check some examples:

1) "legacy serial on Super I/O"

   This is best handled by a asm/serial.h mechanism, something akin
   to how asm/floppy.h works.  Let the platform say how to get at
   the ports.

   Wait, there already is a asm/serial.h that does just this :-)

2) "floppy"

   See asm/floppy.h :-)

3) "PS/2 keyboard and mouse"

   I believe there is an asm/keyboard.h for the keyboard side of this.
   Yes, and it has macros for the register accesses.

4) "legacy keyboard beeper"

   Make an asm/kbdbeep.h or something.

Add whatever else you might be interested that things tend to
inb/outb.

And if your concern is having multiple of these in your system, the
only ones that make sense are floppy and serial and those are handled
just fine by the asm/serial.h mechanism.

This way of doing this allows 16550's, floppies, etc. to be handled on
any bus whatsoever.

I mean, besides this and VGA what is left and even matters?

Later,
David S. Miller
davem@redhat.com


  parent reply	other threads:[~2001-06-14 22:50 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-13 10:02 Going beyond 256 PCI buses Tom Gall
2001-06-13 17:17 ` Albert D. Cahalan
2001-06-13 18:29   ` Tom Gall
2001-06-14 14:14 ` Jeff Garzik
2001-06-14 15:15   ` David S. Miller
2001-06-14 17:59   ` Jonathan Lundell
2001-06-14 20:50     ` Jonathan Lundell
2001-06-14 14:24 ` David S. Miller
2001-06-14 14:32   ` Jeff Garzik
2001-06-14 14:42   ` David S. Miller
2001-06-14 15:29     ` Jeff Garzik
2001-06-14 15:33       ` Jeff Garzik
2001-06-14 18:01   ` Albert D. Cahalan
2001-06-14 18:47   ` David S. Miller
2001-06-14 19:04     ` Albert D. Cahalan
2001-06-14 19:12     ` David S. Miller
2001-06-14 19:41       ` Jeff Garzik
2001-06-14 19:57       ` David S. Miller
2001-06-14 20:08         ` Jeff Garzik
2001-06-14 20:14         ` David S. Miller
2001-06-14 21:30           ` Benjamin Herrenschmidt
2001-06-14 21:46             ` Jeff Garzik
2001-06-14 21:48             ` David S. Miller
2001-06-14 21:57               ` Benjamin Herrenschmidt
2001-06-14 22:12               ` David S. Miller
2001-06-14 22:29                 ` Benjamin Herrenschmidt
2001-06-14 22:49                 ` David S. Miller [this message]
2001-06-14 23:35                   ` Benjamin Herrenschmidt
2001-06-14 23:35                 ` VGA handling was [Re: Going beyond 256 PCI buses] James Simmons
2001-06-14 23:42                 ` David S. Miller
2001-06-14 23:55                   ` James Simmons
2001-06-15 15:14                     ` Pavel Machek
2001-06-15  2:06                   ` Albert D. Cahalan
2001-06-15  8:52                   ` Matan Ziv-Av
2001-06-14 21:35           ` Going beyond 256 PCI buses David S. Miller
2001-06-14 21:46             ` Benjamin Herrenschmidt
2001-06-16 21:32           ` Jeff Garzik
2001-06-16 23:29             ` Benjamin Herrenschmidt
2001-06-15  8:42       ` Geert Uytterhoeven
2001-06-15 15:38       ` David S. Miller
2001-06-14 19:03   ` David S. Miller
2001-06-14 20:56     ` David S. Miller
2001-06-14 15:13 ` Jonathan Lundell
2001-06-14 15:17   ` Jeff Garzik

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=15145.16268.239882.904451@pizda.ninka.net \
    --to=davem@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).