All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Egbert Eich <eich@suse.de>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Xserver development <xorg@freedesktop.org>,
	Jesse Barnes <jbarnes@sgi.com>
Subject: Re: [Linux-fbdev-devel] Re: Who is stomping PCI config space?
Date: Sat, 05 Mar 2005 09:45:04 +1100	[thread overview]
Message-ID: <1109976305.5611.312.camel@gaston> (raw)
In-Reply-To: <9e473391050304095812a11208@mail.gmail.com>

On Fri, 2005-03-04 at 12:58 -0500, Jon Smirl wrote:
> In the past Jesse Barnes has suggested a completely different approach
> to VGA sharing. Instead of each VT trying to control which VGA device
> is enabled we keep them all turned off. Then on each access we turn
> VGA support on just long enough for the access and then turn it back
> off.

That's what I had in mind too.

> To make this work we have to have a kernel based 'token' for who has
> the VGA at the moment. This scheme lets multiuser systems work. For
> big IA64 machines which can support multiple simultaneous VGAs we just
> have multiple tokens.

That means that the arbitrer must need to know how to enable/disable VGA
decoding on a per-card basis (when it's possible at all), or active
collaboration with the kernel driver. Also, you can't prevent the
interrupts from happening unless you also disable them on your card.

> We would just ban VGA access from interrupt context, if you really
> needed VGA access you would use a workqueue which can be scheduled
> from the interrupt. None of my driver work needs VGA access from
> interrupt context, is this true for all drivers? I need access to the
> video hardware, but not access to the VGA support.

It's not enough.

There is a variety of cases where the only way to turn off VGA access is
to turn off IO & MEM decoding completely on the card...

Ben.

  reply	other threads:[~2005-03-04 22:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-03 19:03 Who is stomping PCI config space? Jon Smirl
2005-03-03 23:07 ` Benjamin Herrenschmidt
2005-03-04  0:15   ` Jon Smirl
2005-03-04  3:03     ` Jon Smirl
2005-03-04  6:40       ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2005-03-04 12:07         ` Egbert Eich
2005-03-04 17:35           ` Jon Smirl
2005-03-04 22:42             ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2005-03-05 19:06               ` Egbert Eich
2005-03-05 22:42                 ` Benjamin Herrenschmidt
2005-03-07 11:19                   ` Egbert Eich
2005-03-08  3:21                     ` Benjamin Herrenschmidt
2005-03-05 17:33             ` Egbert Eich
2005-03-04 17:58           ` Jon Smirl
2005-03-04 22:45             ` Benjamin Herrenschmidt [this message]
2005-03-05 19:07               ` Egbert Eich
2005-03-05 22:43                 ` Benjamin Herrenschmidt
2005-03-04 22:27           ` Benjamin Herrenschmidt
2005-03-05 18:26             ` Egbert Eich
2005-03-05 22:39               ` Benjamin Herrenschmidt
2005-03-07 11:05                 ` Egbert Eich
2005-03-04 12:02       ` Egbert Eich
2005-03-04 11:25   ` Egbert Eich
2005-03-04 22:16     ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2005-03-05 17:36       ` Egbert Eich
2005-03-04 11:12 ` Egbert Eich
2005-03-04 22:51   ` Benjamin Herrenschmidt
     [not found] ` <42278AEC.4080706@dunaweb.hu>
2005-03-04 11:21   ` Egbert Eich

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=1109976305.5611.312.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=eich@suse.de \
    --cc=jbarnes@sgi.com \
    --cc=jonsmirl@gmail.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.