public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, mj@suse.cz
Subject: Re: VGA PCI IO port reservations
Date: Fri, 17 Nov 2000 11:36:28 -0500	[thread overview]
Message-ID: <3A155E8C.7D345649@mandrakesoft.com> (raw)
In-Reply-To: <200011171620.eAHGKgg00324@flint.arm.linux.org.uk>

Russell King wrote:
> I've been looking at a number of VGA cards recently, and I've started
> wondering out the Linux resource management as far as allocation of
> IO ports.  I've come to the conclusion that it does not contain all
> information necessary to allow allocations to be made safely.
> 
> Thus far, VGA cards that I've looked at scatter extra registers through
> out the PCI IO memory region without appearing in the PCI BARs.  In fact,
> for some cards there wouldn't be enough BARs to list them all.

> For example, S3 cards typically use:
> 
>  0x0102,  0x42e8,  0x46e8,  0x4ae8,  0x8180 - 0x8200,  0x82e8,  0x86e8,
>  0x8ae8,  0x8ee8,  0x92e8,  0x96e8,  0x9ae8,  0x9ee8,  0xa2e8,  0xa6e8,
>  0xaae8,  0xaee8,  0xb2e8,  0xb6e8,  0xbae8,  0xbee8,  0xe2e8,
>  0xff00 - 0xff44
[...]
> Surely we should be reserving these regions before we start to allocate
> resources to PCI cards?

I tried to push this through when I was hacking heavily on fbdev
drivers, especially S3, and it didn't fly.  On x86's, those addresses
are already reserved:

[jgarzik@rum linux_2_4]$ cat /proc/iomem
00000000-0009efff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
[...]

If they are not reserved on your arch, I think the driver should
definitely reserve the region.  (though if its an ISA-compatible arch,
Linus might desire the above reservations as done by the core, not by
the fbdev driver)

Another alternative I thought of is freeing the resource if it is
allocated by the system, and having the driver allocate its own
resource.  When the driver unloads, it frees its resources and allocates
the whole region back to the system.  I look at this as the fbdev
driver's "clarifying the picture" of the hardware resource usage. 
[again, this hullabaloo might only be necessary on x86]

	Jeff


-- 
Jeff Garzik             |
Building 1024           | The chief enemy of creativity is "good" sense
MandrakeSoft            |          -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-11-17 17:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-17 16:20 VGA PCI IO port reservations Russell King
2000-11-17 16:36 ` Jeff Garzik [this message]
2000-11-17 16:46   ` Russell King
2000-11-17 16:52     ` Jeff Garzik
2000-11-17 16:58       ` Russell King
2000-11-17 17:03         ` Jeff Garzik
2000-11-17 17:11           ` Russell King
2000-11-17 21:43     ` Matthew Kirkwood
2000-11-17 22:02       ` H. Peter Anvin
2000-11-18 17:41         ` About IOs, ISA, PCI, and life (WAS: VGA PCI IO port...) Benjamin Herrenschmidt
2000-11-17 17:13   ` VGA PCI IO port reservations Richard B. Johnson
2000-11-17 17:20     ` Russell King
2000-11-17 17:30       ` Alan Cox
2000-11-17 18:06       ` Richard B. Johnson
2000-11-17 19:52         ` Russell King
2000-11-17 19:59           ` Richard B. Johnson
2000-11-17 20:02             ` Russell King
2000-11-17 20:27               ` Richard B. Johnson
2000-11-18  1:20                 ` Olivier Galibert
2000-11-18  2:10                   ` H. Peter Anvin
2000-11-18 17:02                     ` Alan Cox
2000-11-27 22:10                       ` Kai Henningsen
2000-11-17 21:35             ` Marcus Sundberg
2000-11-17 20:13           ` H. Peter Anvin
2000-11-17 20:31             ` Richard B. Johnson
2000-11-17 16:47 ` Brian Gerst
2000-11-17 16:56   ` Russell King
2000-11-17 17:00     ` Jeff Garzik
2000-11-17 18:29     ` H. Peter Anvin
2000-11-17 18:27 ` H. Peter Anvin

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=3A155E8C.7D345649@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mj@suse.cz \
    --cc=rmk@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