From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: xorg@freedesktop.org, Egbert Eich <eich@freedesktop.org>,
Jon Smirl <jonsmirl@yahoo.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] VGA arbitration: draft of kernel side
Date: Wed, 09 Mar 2005 11:02:45 +1100 [thread overview]
Message-ID: <1110326565.32556.7.camel@gaston> (raw)
In-Reply-To: <9e47339105030815477d0c7688@mail.gmail.com>
On Tue, 2005-03-08 at 18:47 -0500, Jon Smirl wrote:
> This very similar to the reset support patch I have been working on.
>
> In the reset patch there is a 'vga' attribute on each VGA device. Set
> it to 0/1 to make the device active. This lets you move the console
> around betweem VGA devices.
>
> You can also set it to 3, which disables all VGA devices but remembers
> the active one. Setting it to 4 disables all VGA devices then restores
> the active one. To use, set it to 3, post, set it to 4.
>
> GregKH wants this code out of the pci directory but it needs hooks
> into pci_destroy_dev() to delete the arbiter. You also need a hook on
> add for when a hotplug device appears.
>
> I'll try merging my sysfs support into your code.
Please wait.
I don't want that semantic for sysfs. First, I don't want to "move
around" the VGA device. This is very arch specific and will not work in
a variety if circumstances. Also, "outb's" to legacy VGA ports will only
work with some PCI domains on archs like PPC, even vgacon can't deal
with that, so let's avoid putting such "knowledge" in the arbiter
itself. I prefer for now defining a "default" vga device which is the
one used by vgacon. If you want to move vgacon around, do some arch
specific stuff or add way to change the default device, but that isn't
directly related to the arbitration process.
Also, I want the sysfs entry (or /dev if I can't get the proper
semantics in sysfs) to have open & release() callbacks like a char
device. The reason is that I want the vga "locks" owned by a process to
be automatically released if the process dies. Without that, kill -9 on
X will end up requiring a reboot in most circumstances :)
Finally, I want to keep the distinction between memory and IO enables.
That's quite important imho, since a lot of cards can operate with IO
disabled (all ATIs for example), which is good as I'm not completely
sure I can disable legacy IO port decoding on them (well, I don't know
how to do it).
Ben.
next prev parent reply other threads:[~2005-03-09 0:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-08 7:11 [PATCH] VGA arbitration: draft of kernel side Benjamin Herrenschmidt
2005-03-08 21:29 ` Kronos
2005-03-08 22:46 ` Benjamin Herrenschmidt
2005-03-09 10:22 ` Pekka Enberg
2005-03-09 20:06 ` Kronos
2005-03-08 22:01 ` Benjamin Herrenschmidt
2005-03-08 23:47 ` Jon Smirl
2005-03-09 0:02 ` Benjamin Herrenschmidt [this message]
2005-03-09 3:17 ` Jon Smirl
2005-03-09 3:53 ` Benjamin Herrenschmidt
2005-03-09 4:35 ` Jon Smirl
2005-03-09 5:37 ` Benjamin Herrenschmidt
2005-03-09 5:58 ` Jon Smirl
2005-03-09 6:00 ` Benjamin Herrenschmidt
2005-03-09 8:04 ` Benjamin Herrenschmidt
2005-03-09 16:57 ` Jesse Barnes
2005-03-09 10:45 ` Pekka Enberg
2005-03-09 22:02 ` Benjamin Herrenschmidt
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=1110326565.32556.7.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=eich@freedesktop.org \
--cc=jonsmirl@gmail.com \
--cc=jonsmirl@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xorg@freedesktop.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