Andi Kleen <[EMAIL PROTECTED]> writes: > On Mon, Dec 17, 2007 at 08:57:50AM +1100, Paul Mackerras wrote: >> Greg KH writes: >> >> > Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs >> > devices that are mmaped, that makes a bit more sense. >> > >> > But I'd like to see what ioctl is wanted here first. >> >> I believe the ioctl would be to set whether the mapping goes to I/O or >> memory space, > > x86 cannot really access IO space through mmap so no that wasn't planned
0000_00FD_FC00_0000h - 0000_00FD_FDFF_FFFFh On a hypertransport based system should work. There is a 32MB window for it. However the I/O vs mem distinction doesn't matter anyway if we start out per bar because we already know if it is I/O or mem. > The main planned use was to get the translated bus address (after IOMMU) > for a mapping and to set the caching modes. > >> So the alternative to the ioctl would be to have multiple files in >> sysfs, one per combination of modes -- i.e., 4 files, or 3 if we >> exclude the "I/O with write combining" mode, which would be >> reasonable. > > At least for the IOMMU translation case that wouldn't work. Well the other alternative looks like having a second file per par bar. Say resource0_wc to support the write-combining mode, possibly restricted to just prefetchable bars. If that is all we have to worry about my inclination is to suggest a second file, because that feels a bit more generally useable. As that attribute could be applied to ordinary reads and writes to and from the bar. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/