Re: pci-sysfs resource mmap broken (and PATCH)

["David S. Miller" <davem@davemloft.net>]

On Wed, 27 Apr 2005 23:33:11 -0600
Grant Grundler <grundler@parisc-linux.org> wrote:

> I would expect the mmap() return value to point at the base of
> whatever thing it is that I handed it. And everything is relative
> to that within the range that I ask be mmap'd.

The 'offset' argument is defined to be page aligned
when passed to mmap().

> If it's a token, the arch specific mmap() will know how to deal with it.
> parisc does that with IO Port space(s) in the kernel.

Yes, if the token goes in as the offset parameter to mmap() then
whatever ->mmap() code we write can call arch specific code to
transform it as necessary.

> This is similar to davem's reminder about 32-bit user space on 64-bit
> platform. I expect some form of token will need to be used if user
> space can't be taught/forced to use 64-bit values coming from
> either /sys or /proc. It's probably best to leave /proc untouched
> and only mangle /sys so it always prints 64-bit values.

Let's make sys use 64-bit, yes.

> I didn't know anything about pci_mmap_page_range().
> parisc and alpha don't implement it. And both translate the IO View
> (BAR values) to CPU view (resource) for MMIO space.

It's been around for ages, and it used in the X server on PPC
and Sparc.  It mostly allows handling of multi-domain stuff.
Unfortunately, the $DOMAIN:xxx directory naming change we made
in 2.6.x for /proc/pci stuff broke the X server at least on
sparc64 :-/

> sys-fs support also uses it:
> 
> grundler <533>fgrep HAVE_PCI_MMAP drivers/pci/*
> drivers/pci/pci-sysfs.c:#ifdef HAVE_PCI_MMAP
> drivers/pci/pci-sysfs.c:#else /* !HAVE_PCI_MMAP */
> drivers/pci/pci-sysfs.c:#endif /* HAVE_PCI_MMAP */
> 
> Documentation/filesystems/sysfs-pci.txt at least mentions which
> parameters can be passed to mmap and what the arch must provide.

I hate to say this, but the largest consumer of this stuff is the
X server, so we really need to force ourselves to work in parallel
on clean X server support.  Whether that's via some libpci.a
abstraction or whatever, I personally don't care, but without the
X support in some form all of this is API masterbation :-)

> If it's prefetchable, won't the reads/writes automatically be combined?
> Since I equate "prefetchable" == "cacheable", I'd think anything
> is fair game.

On many platforms some kind of "side effect" bit in the PTE
determine if store buffer compression can happen in the processor.
We'd want to not set such a bit for things like frame-buffers and
the like.

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