Messages in this thread | | | Date | Wed, 27 Apr 2005 22:37:02 -0700 | From | "David S. Miller" <> | Subject | Re: pci-sysfs resource mmap broken (and PATCH) |
| |
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/
| |