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: Mon, 7 Mar 2005 12:05:10 +0100 [thread overview]
Message-ID: <16940.13670.840807.311073@xf14.local> (raw)
In-Reply-To: benh@kernel.crashing.org wrote on Sunday, 6 March 2005 at 09:39:50 +1100
Benjamin Herrenschmidt writes:
>
> Yes, you can assume the worst case at first, and later on have the
> driver disable decoding of legacy stuff and inform your arbiter to stop
> caring about that specific card, no ?
Right. Actually we had different mechanisms implemented and I also
had the concept of 'background' driver which would just do this
without driving any card.
Unfortunately this has never really been employed much and I would
have to look how this was designed in detail.
> >
> > On a lot of cards there may be situations where VGA registers need to
> > be accessed for specific purposes.
>
> Yup, though "modern" cards usually don't. A radeon operates 100% without
> access to any legacy resource lately (except the console restore on
> console switch, but that's fairly isolated and I even removed it on ppc
> as it breaks things on setups where the card was boostrapped in "no VGA"
> mode. I personally think it should be done by the kernel). I think
> nvidia's "remap" the VGA registes somewhere in normal MMIO space, at
> least I think I remember seeing something like that.
How about POSTing? Doesn't the Radeon card have to be POSTed?
>
> > Furthermore it must not be expected that nobody uses older cards which
> > still require VGA registers.
>
> Agreed.
>
> > 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?
>
> Not really. Well, something could be hacked, that is, the current CPU is
> obviously handling the IRQ, so the process "below" has been halted, but
> it would require some kind of IPI tricks to also halt other CPUs, quite
> heavy handed I think.
Yes, that's what I was asking. Would there be a way to avoid too
much overhead in the kernel?
But maybe your suggestion how to handle the situation where interrupt
handling that required VGA resources could be dealt with outside the
interrupt handler would be sufficient for all cases where this may
matter.
>
> > All this would only matter for systems with more than one CPU.
>
> Yes, but those are becoming quite common. Also multicore is coming ;)
>
I agree.
Cheers,
Egbert.
next prev parent reply other threads:[~2005-03-07 11:05 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
2005-03-05 22:39 ` Benjamin Herrenschmidt
2005-03-07 11:05 ` Egbert Eich [this message]
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=16940.13670.840807.311073@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).