mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Jesse Barnes <jbarnes@sgi.com>
Cc: Grant Grundler <grundler@parisc-linux.org>,
	Jon Smirl <jonsmirl@gmail.com>, Greg KH <greg@kroah.com>,
	Russell King <rmk+lkml@arm.linux.org.uk>,
	Jeff Garzik <jgarzik@pobox.com>, Matthew Wilcox <matthew@wil.cx>,
	linux-pci@atrey.karlin.mff.cuni.cz,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: Fwd: Patch to control VGA bus routing and active VGA device.
Date: Fri, 28 Jan 2005 12:33:20 -0700	[thread overview]
Message-ID: <20050128193320.GB32135@colo.lackof.org> (raw)
In-Reply-To: <200501281041.42016.jbarnes@sgi.com>

On Fri, Jan 28, 2005 at 10:41:41AM -0800, Jesse Barnes wrote:
> > Eh?! there can only be *one* legacy I/O space.
> > We can support multipl IO port spaces, but only one can be the "legacy".
> 
> What do you mean?  If you define legacy I/O space to be 
> 0x0000000000000000-0x000000000000ffff, then yes of course you're right.

Yes - exactly.

> But 
> if you mean being able to access legacy ports at all, then no.  On SGI 
> machines, there's a per-bus base address that can be used as the base for 
> port I/O, which is what I was getting at.

Ok - my point was "0x3fc" will get routed to exactly one of those
IO port address spaces.

> > If it is intended to work with multiple IO Port address spaces,
> > then it needs to use the pci_dev->resource[] and mangle that appropriately.
> 
> There is no resource for some of the I/O port space that cards respond to.

Yes - I've heard several graphics cards are horrible broken WRT address
decoding.  Are PCI quirks supposed to handle that sort of thing?

Another example was Xf86 was poking around in MMIO space 
to determine if such broken cards are installed.

> I can set the I/O BAR of my VGA card to 0x400 and it'll still respond to 
> accesses at 0x3bc for example.  That's what I mean by legacy space--space 
> that cards respond to but don't report in their PCI resources.

Can't PCI quirks fix up the resources to reflect this?

I think one needs to fix up PCI IO Port resources to adjust
for "The One" legacy IO port space getting routed to a different
PCI segment - assuming no one submits a patch to change current
behavior of using hard coded addresses.

HP parisc and ia64 platforms implement seperate PCI segments under
each PCI host bus controller. Linux PCI "BIOS" support provides
the illusion it's all in one PCI segment on most (not all) platforms.
Some HP chipsets also provide a "Legacy" IO Port space that gets
routed to a chosen PCI Host bus controller.

parisc PCI BIOS adds the controller instance number to the IO port space
resource to help "inb()" generate the IO port cycle on the right
PCI segment. This needs to be fixed up if we decide a different
PCI segment should be segment 0 (and thus get references to 0x3fc).
I expect other arches with multi-segment support to do similar
fix ups.

Am I making more sense now?

thanks,
grant

  reply	other threads:[~2005-01-28 19:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-18  3:43 Jon Smirl
2005-01-18 17:46 ` Jesse Barnes
2005-01-18 19:38   ` H. Peter Anvin
2005-01-18 21:06     ` Jesse Barnes
2005-01-22 19:04       ` Jon Smirl
2005-01-24 17:25         ` Jesse Barnes
2005-01-24 17:53           ` Jesse Barnes
     [not found] ` <41ED3BD2.1090105@pobox.com>
     [not found]   ` <9e473391050122083822a7f81c@mail.gmail.com>
     [not found]     ` <200501240847.51208.jbarnes@sgi.com>
     [not found]       ` <20050124175131.GM31455@parcelfarce.linux.theplanet.co.uk>
2005-01-24 19:17         ` Fwd: " Jon Smirl
2005-01-24 19:42           ` Jeff Garzik
2005-01-24 19:55             ` Russell King
2005-01-24 23:11               ` Jon Smirl
2005-01-25  4:24               ` Greg KH
2005-01-27  9:59                 ` Jon Smirl
2005-01-27 16:28                   ` Jesse Barnes
2005-01-28 17:32                     ` Grant Grundler
2005-01-28 18:36                       ` Jon Smirl
2005-01-28 19:15                         ` Grant Grundler
2005-01-28 19:26                           ` Jon Smirl
2005-01-28 19:34                             ` Grant Grundler
2005-01-28 18:41                       ` Jesse Barnes
2005-01-28 19:33                         ` Grant Grundler [this message]
2005-01-28 19:41                           ` Jesse Barnes
2005-01-28 20:12                             ` Grant Grundler
2005-01-28 20:00                           ` Matthew Wilcox
2005-01-28 20:07                             ` Russell King
2005-01-31 16:01                             ` Alan Cox
2005-02-01  6:38                   ` Greg KH
2005-02-01 16:24                     ` Jon Smirl
2005-01-30  7:51                 ` Jon Smirl
2005-01-24 20:14             ` Matthew Wilcox
2005-01-24 20:22           ` Matthew Wilcox

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=20050128193320.GB32135@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=greg@kroah.com \
    --cc=jbarnes@sgi.com \
    --cc=jgarzik@pobox.com \
    --cc=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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

all inboxes | Powered by JetHome®