linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linus.walleij@linaro.org (Linus Walleij)
To: linux-arm-kernel@lists.infradead.org
Subject: Integrator PCI base dilemma
Date: Thu, 21 Mar 2013 10:16:40 +0100	[thread overview]
Message-ID: <CACRpkdbLjhg-EuTBM4-_-xWV+_dDoA-RNo3FOUDN8Ka0w77sGA@mail.gmail.com> (raw)
In-Reply-To: <514A4C30.9080402@gmail.com>

On Thu, Mar 21, 2013 at 12:54 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 03/20/2013 06:15 PM, Linus Walleij wrote:

>> - Unable to assign vga_base early since this should be a virtual
>>   address assigned really early. If I sacrifice this and try to
>>   just remap the stuff, I still run into:
>
> This could be a fixed mapping like we did for the i/o space.

Hm, can you point me to the relevant topics so I can read up on it?

> Wouldn't the drivers' ioremap create a mapping with the the memory
> space? The only user of this mapping may be VGA.

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

> 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 :-/

Yours,
Linus Walleij

  reply	other threads:[~2013-03-21  9:16 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 [this message]
2013-03-21 13:22     ` Rob Herring
2013-03-21 16:17       ` Arnd Bergmann
2013-03-22 11:05       ` Russell King - ARM Linux
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=CACRpkdbLjhg-EuTBM4-_-xWV+_dDoA-RNo3FOUDN8Ka0w77sGA@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --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).