![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2005-04-28 05:55 [from the cache] ©2003-2008 | ||||||||||