From: Egbert Eich <eich@suse.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Egbert Eich <eich@suse.de>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>,
Xserver development <xorg@freedesktop.org>,
Egbert Eich <eich@pdx.freedesktop.org>
Subject: Re: [Linux-fbdev-devel] Re: Who is stomping PCI config space?
Date: Sat, 5 Mar 2005 19:26:39 +0100 [thread overview]
Message-ID: <16937.63967.588170.359548@xf14.local> (raw)
In-Reply-To: benh@kernel.crashing.org wrote on Saturday, 5 March 2005 at 09:27:19 +1100
Ben,
Benjamin Herrenschmidt writes:
> > The point is: if Jon needs these registers in an interrupt handler
> > he may have to tweak PCI config space form there anyway since another
> > card may currently have VGA routed.
>
> The problem is that a card that has VGA support _and_ MMIO registers.
> Even if nobody uses VGA on it, if a different VGA card on the same bus
> is active, X will disable IO decoding on the first one (to disable VGA
> too).
Right. And without any driver support it is difficult to know if the
card decodes legacy resources or if this decoding is turned off.
I can do waht Jon suggested and use the 'industry standard' VGA disable
registers.
Depending on the card those registers may disable more than just VGA.
>
> There isn't a simple way to solve that that I know, except if the card
> can be configured to totally ignore VGA accesses, in which case it
> doesn't need to be disabled, but X doesn't know it... (though if we
> have a central "arbibrer", the driver for the card can tell it to remove
> that card from the arbitration).
Right. But we don't load the driver.
>
> In the normal case tho, I don't really see how to deal with that other
> than, indeed, switching the enables at interrupt time, when the IRQ gets
> in, which will obviously conflict with a concurrent server working on
> the "other" card at the same time....
On a multi-CPU system this can be a problem as one CPU may work on
the previously enabled VGA card while the other one tries to service
the VGA card that has sent the interrupt.
>
> So even with a kernel based arbitrer, the irq scenario isn't possible to
> deal with properly, unless VGA decoding can be completely disabled on a
> given card, or nobody uses VGA memory accesses on any card. (Most modern
> drivers only use non-VGA memory/IO, or even IO are remapped to some
> different addresses with some cards).
On a lot of cards there may be situations where VGA registers need to
be accessed for specific purposes.
Furthermore it must not be expected that nobody uses older cards which
still require VGA registers.
Is there a way to halt a process that is using VGA registers for the
time the interrupt gets serviced? For example sending a signal to
this process so that it suspends norml execution waits in a signal
handler?
All this would only matter for systems with more than one CPU.
Cheers,
Egbert.
next prev parent reply other threads:[~2005-03-05 18:26 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
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 [this message]
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=16937.63967.588170.359548@xf14.local \
--to=eich@suse.de \
--cc=benh@kernel.crashing.org \
--cc=eich@pdx.freedesktop.org \
--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 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).