linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: Integrator PCI base dilemma
Date: Fri, 22 Mar 2013 11:05:31 +0000	[thread overview]
Message-ID: <20130322110531.GX4977@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <514B098E.8020608@gmail.com>

On Thu, Mar 21, 2013 at 08:22:22AM -0500, Rob Herring wrote:
> On 03/21/2013 04:16 AM, Linus Walleij wrote:
> > Well the VGA console is supposed to be as early as possible so
> > in some sense it's like an earlyprint dilemma. The way the mechanism
> > works right now is to give a raw pointer into the remapped
> > PCI non-prefetched memory, then the VGA console assumes that
> > the VGA device will be right there, att offset zero.
> > 
> > (Maybe there is some guarantee that PCI VGA devices will appear
> > first in that memory space, or it would be hard to do stunts like
> > this... I admit I haven't done much of PCI in my life.)
> 
> I believe it is setup by the BIOS and fixed on x86. There's probably
> some bootloader setup assumptions for ARM.

All VGA cards need to be initialized before use.  On x86, that happens as
a result of the BIOS loading and running an BIOSes on any cards in the
system - starting with any VGA BIOS first.  VGA BIOSes do all sorts of
different weird stuff, so running them on non-x86 is non-trivial.  VGA
BIOSes can and do poke at other bits of PC hardware.

> Does VGA need all 16MB as well?

The only real chunk that needs to be mapped is the 640K-1MB region, which
is what x86 "removes" from system RAM and uses for VGA and BIOSes.

> >> For the config space, how much do you really need? You could ioremap
> >> this on demand. I think this issue came up before on another platform
> >> where the config space was very sparsely accessed.
> > 
> > Yes I think you're right here. So there may be a way to avoid the
> > big chunk of 16MiB remapping and avoid using a static offset for this.
> > 
> > So I end up only keeping one 16MiB remapping for the memory and
> > another static mapping for the I/O memoryspace.
> > 
> > And we basically have no way to get rid of these static maps :-/
> 
> You don't really have to get rid of the static map necessarily. It just
> needs to be more generic. If you fix the virtual address across
> platforms, then you just need to get the phys address out of the DT.

Exactly.

  parent reply	other threads:[~2013-03-22 11:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 23:15 Integrator PCI base dilemma Linus Walleij
2013-03-20 23:54 ` Rob Herring
2013-03-21  9:16   ` Linus Walleij
2013-03-21 13:22     ` Rob Herring
2013-03-21 16:17       ` Arnd Bergmann
2013-03-22 11:05       ` Russell King - ARM Linux [this message]
2013-03-21 13:02 ` Arnd Bergmann
2013-03-21 23:40   ` Russell King - ARM Linux
2013-03-22  9:48     ` Arnd Bergmann
2013-03-22 10:37       ` Russell King - ARM Linux
2013-03-22 11:52         ` Arnd Bergmann
2013-03-22 12:12           ` Russell King - ARM Linux
2013-03-22 12:34             ` Arnd Bergmann
2013-03-22 18:33               ` Jason Gunthorpe
2013-03-22 18:35                 ` Russell King - ARM Linux
2013-03-22 19:22         ` Linus Walleij
2013-03-22 20:05           ` Arnd Bergmann
2013-03-22 21:13           ` Wolfgang Denk
2013-03-22 22:35             ` Linus Walleij
2013-03-22 23:48               ` Russell King - ARM Linux
2013-03-23  0:19               ` Wolfgang Denk

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=20130322110531.GX4977@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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).