public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@sgi.com>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: 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 11:41:16 -0800	[thread overview]
Message-ID: <200501281141.16450.jbarnes@sgi.com> (raw)
In-Reply-To: <20050128193320.GB32135@colo.lackof.org>

On Friday, January 28, 2005 11:33 am, Grant Grundler wrote:
> > 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.

Agreed, or it will cause a machine check if legacy I/O remapping isn't 
supported (like on SGI).

> > 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?

I'm not sure if broken is the right work.  All this stuff predates PCI by 
quite a bit, so certain device classes claimed certain port ranges way before 
cards were required to have programmable address decoders.  VGA cards are 
probably the most tenacious example of this, they respond to certain well 
known ports after reset, regardless of BAR values.

> > 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?

Not sure, the I/O BAR may correspond to real registers too--and they may not 
overlap with the ones in the well known space.

> 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.

I think we might just need a new resource for these well known ports, if my 
last statement is true.

> Am I making more sense now?

Yeah, I think I understand.  We could probably do the same thing on sn2 as you 
do on parisc--add a 'segment 0' offset to the port so that it's routed 
correctly.  I think that's a little less flexible than adding a new resource 
though, since it makes it harder for drivers to support more than one device 
or devices on non-segment 0 busses.

Jesse

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

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-18  3:43 Patch to control VGA bus routing and active VGA device 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
2005-01-28 19:41                           ` Jesse Barnes [this message]
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=200501281141.16450.jbarnes@sgi.com \
    --to=jbarnes@sgi.com \
    --cc=greg@kroah.com \
    --cc=grundler@parisc-linux.org \
    --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