linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: Egbert Eich <eich@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Xserver development <xorg@freedesktop.org>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Egbert Eich <eich@pdx.freedesktop.org>
Subject: Re: Re: Who is stomping PCI config space?
Date: Fri, 4 Mar 2005 12:35:20 -0500	[thread overview]
Message-ID: <9e47339105030409352803c7e1@mail.gmail.com> (raw)
In-Reply-To: <16936.20345.249542.65736@xf14.local>

On Fri, 4 Mar 2005 13:02:34 +0100, Egbert Eich <eich@suse.de> wrote:
> you know well that we are not living in the same time zone, so you
> may want to give me some time to answer.

I was getting upset that when I did a VT switch my machine was hard
locking and I had to keep rebooting all of the time to debug the
problem. I had spent many hours trying to find the problem in my code
and it wasn't there. I was not expecting X to alter the state of
hardware it did not have a driver loaded for.

> It needs to have it in some central place which doesn't necessarily
> have to be the kernel.
> 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.
> 
>  >
>  > X disables any other VGA card IO/MEM in the system so that at one given
>  > point in time, only one of them will decode VGA cycles. Wether it has
>  > those cards to drive in it's config or not doesn't matter, the problem
>  > at the bus level is the same.
> 
> Right. It however should only do so if one of the cards it is driving
> itself requires VGA registers for its mode of operation.

Ok, now I see what X is doing. It is making sure there is only one
active VGA device in the system.  However, my framebuffer driver is
not using VGA mode.

I have similar code in my VGA support patch but I only shut down the
card mem/io long enough to turn off VGA support. I don't leave the
whole card turned off. I also see now that I should shut interrupts
off while doing this.

pci_read_config_word(pdev, PCI_COMMAND, &command);
pci_write_config_word(pdev, PCI_COMMAND, command | PCI_COMMAND_IO |
PCI_COMMAND_MEMORY);

vga_io_w(0x3C3, ~0x01 & vga_io_r(0x3C3));
vga_io_w(0x46e8, ~0x08 & vga_io_r(0x46e8));
vga_io_w(0x102, ~0x01 & vga_io_r(0x102));

pci_write_config_word(pdev, PCI_COMMAND, command);

If we leave the whole card turned off I can't access the interrupt
status registers to acknowledge the interrupt and shut it off.

Does this approach work for X? Where is the code that does this at VT
switch time?

On VT enter X would need to:
1) shut off interrupts
2) disable IO/MEM on all VGA cards - remember IO/mem state
3) turn the cards on one at a time and disable VGA - remember VGA enable state
4) restore IO/MEM state to all cards
5) turn interrupts back on

On VT exit:
1) shut off interrupts
2) disable IO/MEM on all VGA cards - remember IO/mem state
3) restore VGA enable state
4) restore IO/MEM state to all cards
5) turn interrupts back on

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

  reply	other threads:[~2005-03-04 17:35 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 [this message]
2005-03-04 22:42             ` 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
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=9e47339105030409352803c7e1@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=eich@pdx.freedesktop.org \
    --cc=eich@suse.de \
    --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).