From: Matt Porter <mporter@mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Hollis <hollis-lists@austin.rr.com>,
linuxppc-dev@lists.linuxppc.org, Matt Porter <mporter@mvista.com>
Subject: Re: PReP and generic PCI resource assignment
Date: Thu, 9 Aug 2001 09:14:02 -0700 [thread overview]
Message-ID: <20010809091402.A11768@beef.az.mvista.com> (raw)
In-Reply-To: <20010809101833.16835@smtp.adsl.oleane.com>; from benh@kernel.crashing.org on Thu, Aug 09, 2001 at 12:18:33PM +0200
On Thu, Aug 09, 2001 at 12:18:33PM +0200, Benjamin Herrenschmidt wrote:
> >At any rate, relocating PCI resource 1 on this controller from 0x0 to
> >0x01000000 causes my VGA console to go backwards endian. I don't know why
> >this would be the case... Re-moving it back to 0x0 fixes the symptom. Any
> >ideas on why this could happen? I think VGA is all IO, no memory at all?
>
> VGA is both IO and memory. It's possible that your VGA card is so broken
> that it only use the low-order bits of addresses and use the high addresses
> as flags, for example to access a "bug endian" aperture :) That would suck
> as it would mean you actually have address aliasing going on on the bus,
> possiby causing weird conflicts.
>
> >I'm curious about PCIBIOS_MIN_MEM... Why does that exist, and why was it
> >given that value?
>
> Note sure, I don't really like the way it's used and hard coded....
That "generic" code has caused me a number of problem on many PCI
equipped embedded platforms (not just PPC ones). The algorithm
used to pick PCI Mem space addresses ignores the fact that there are
specific areas in CPU address space captured to generate mem cycles.
>From my read of the code, it simply picks any old address that's
not claimed by another resource starting at PCIBIOS_MIN_MEM. That's
braindead and probably just another x86ism that'll work on those
platforms.
This is why I always use the pci_auto.c code to properly place base
addresses so the PCI resource system won't try to use it's braindead
algorithm to move them around.
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-08-09 16:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-08 5:11 PReP and generic PCI resource assignment Hollis
2001-08-08 5:43 ` ashish anand
2001-08-08 12:23 ` Benjamin Herrenschmidt
2001-08-08 10:27 ` Benjamin Herrenschmidt
2001-08-09 1:34 ` Hollis
2001-08-09 10:18 ` Benjamin Herrenschmidt
2001-08-09 16:14 ` Matt Porter [this message]
2001-08-10 8:38 ` Geert Uytterhoeven
2001-08-10 9:56 ` Benjamin Herrenschmidt
2001-08-10 10:51 ` Geert Uytterhoeven
2001-08-10 19:34 ` Hollis Blanchard
2001-08-11 17:43 ` Geert Uytterhoeven
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=20010809091402.A11768@beef.az.mvista.com \
--to=mporter@mvista.com \
--cc=benh@kernel.crashing.org \
--cc=hollis-lists@austin.rr.com \
--cc=linuxppc-dev@lists.linuxppc.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).