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 12:12:18 +0000	[thread overview]
Message-ID: <20130322121218.GD4977@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <201303221152.07569.arnd@arndb.de>

On Fri, Mar 22, 2013 at 11:52:07AM +0000, Arnd Bergmann wrote:
> On Friday 22 March 2013, Russell King - ARM Linux wrote:
> > On Fri, Mar 22, 2013 at 09:48:27AM +0000, Arnd Bergmann wrote:
> > > > That's because it's pretty much built into the way VGA crud works.
> > > > VGA BIOSes hard code these addresses into themselves.  Really, so does
> > > > the kernel, but non-native architectures are given the chance to offset
> > > > this appropriately - and remember that non-native architectures will
> > > > run the VGA BIOS via an x86 emulator, which you pretty much have to do
> > > > to get VGA cards to initialize properly.
> > > 
> > > Unfortunately, the offsetting also means that you have a non-zero mem_offset
> > > value for the pci host controller, which breaks code that reads the PCI BARs
> > > and uses those as physical addresses.
> > 
> > No, you're confusing two things.
> > 
> > Firstly, nothing in todays kernel should read PCI BARs and treat them as
> > physical addresses.  Userspace is a different matter, but that is entirely
> > unrelated to VGA_MAP_MEM().
> 
> I understand the part about "should", and I would hope that there is little
> code left in the kernel still doing that, but I occasionally see some of
> that in old or staging drivers. Try "git grep PCI_BASE_ADDRESS" in the kernel
> tree.

Well, anything which does stuff like this:

            for (i = 0xC8000; i < 0xE8000; i += 0x4000) {
                ha->brd = ioremap(i, sizeof(u16));
                pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, i);

is broken for a whole load of reasons not just because of the write to
the PCI configuration register.  The same probably applies elsewhere.

> It's not completely wrong, it's picking one of two evils. VGA console
> is the only thing that needs the low PCI address mapping, and if you
> have any more recent GPU, you can use fbcon with a hardware specific
> driver that uses the normal PCI BARs.

I'm afraid that is not entirely true.  Many VGA cards require access
to the VGA window to access MMIO registers to tell them what to do...
And remember my earlier point - you must have something to run the
VGA BIOS to setup the VGA card, and it _will_ want to initialize it
in VGA mode using the VGA window.  So if you can't access that on
your PCI bus, you can't ever have a VGA card plugged in.

> Also, in many cases, you don't even have the choice in the kernel between
> the two options, either PCI is identity mapped or mapped starting at
> address zero based on whatever the soc or board designer thought, and the
> only thing we can do is tell the kernel what the hardware does.

Exactly which is why you're wrong. :)  If the hardware enforces a
separation of the physical address space from the PCI address space
by way of an offset translation, then you have no option but to have
a non-zero mem_offset.

> It looks like cns3xxx, tegra, versatile and ks8695 are all hardwired to a
> zero mem_offset, while dc21285, integrator, it8152 and sa1100/pci-nanoengine
> map the PCI bus starting at bus address 0.

Don't read too much into the versatile stuff.  All that is very very much
untested and fragile.  It's fairly buggered at the moment as it stands,
and as far as I can tell there's absolutely no way to know what the right
solution is - because the ARM documentation is extremely poor and all the
real hardware has been stuffed through the mincer.

So that leaves cns3xxx, tegra and ks8695 being the non-plat ones which
are "different" from the majority on ARM.

  reply	other threads:[~2013-03-22 12:12 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
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 [this message]
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=20130322121218.GD4977@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).