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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
