Subject: PCI userland access non-mmap APIs, kernel access to legacy space
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linux-pci@atrey.karlin.mff.cuni.cz
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
       Matthew Wilcox <matthew@wil.cx>, Greg KH <greg@kroah.com>,
       Ian Romanick <idr@us.ibm.com>, Jeff Garzik <jgarzik@pobox.com>
Content-Type: text/plain
Date: Mon, 18 Jun 2007 12:16:44 +1000
Message-Id: <1182133004.26853.229.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2645
Lines: 65

Hi folks !

Before I start actually writing code, I want to do a quick brain dump
here to see if there are any objections.

So a problem we have is that on non-x86, we expect to be able to access
PCI IO space via mmap'ing of sysfs based "resource" files.

However, there are various PCI host bridges out there that don't make
that a practical solution. So far, I have two cases on ppc of bridges
that either use indirect access for the IO space or require specific HW
workarounds on accesses that involve spinlocks (to properly deal with
the non-posted aspect of IO transactions). In addition, Lennert tells me
that similar issues exist on ARM.

Thus, I would like to introduce an additional read/write interface to
sysfs "resource" files (and then get Ian's libpciaccess use that when
mmap is unavailable).

In fact, it's funny in a way becauase the "legacy" files interface is
already read/write based (exclusively even, mmap isn't supported) for
legacy IOs.

I beleive that doing so is better than trying to extend /dev/port to
understand multiple domains, >64K IO space, etc... etc...., because you
don't have to understand all the remapping tricks that the operating
system might be doing behind the scene, just open the resource file (or
the legacy file of that bus for legacy accesses) and read/write to it.

Any objection ?

Also, while at it, I would like to introduce a pair of in-kernel
interfaces:

int pci_translate_legacy_resource(struct pci_bus *bus, struct resource *res);

Which takes a resource containing an absolute legacy range on that bus
(for example, an IO resource with the VGA port numbers, or a memory
resource with the VGA text mode aperture). That resource is then
"converted" for the given PCI bus. For x86, that function would boil
down to "return 0;".

The reason is that on multiple domains machines, it's actually not
trivial to figure out where the legacy space of a given domain is
mapped, if available at all. The above function is a way to solve that
problem, allowing things like vgacon to work in multi-domains setup
without half of the current arch specific hacks in there.

That would be also allowed to fail (some platforms can't give access to
legacy memory or legacy IOs at all).

We could probably even implement the pci sysfs "legacy" interface on top
of these as well, thus making it generic to all platforms.

Any objection there too ?

Cheers,
Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/