Andi Kleen <[EMAIL PROTECTED]> writes:
>> Well the other alternative looks like having a second file per par
>> bar. Say resource0_wc to support the write-combining mode, possibly
>
> The intention was to support memory not in bars, but give a generic
> IOMMU mapped memory interface for user
> Well the other alternative looks like having a second file per par
> bar. Say resource0_wc to support the write-combining mode, possibly
The intention was to support memory not in bars, but give a generic
IOMMU mapped memory interface for user space e.g. for the X server.
But that needs a way
Well the other alternative looks like having a second file per par
bar. Say resource0_wc to support the write-combining mode, possibly
The intention was to support memory not in bars, but give a generic
IOMMU mapped memory interface for user space e.g. for the X server.
But that needs a way to
Andi Kleen [EMAIL PROTECTED] writes:
Well the other alternative looks like having a second file per par
bar. Say resource0_wc to support the write-combining mode, possibly
The intention was to support memory not in bars, but give a generic
IOMMU mapped memory interface for user space e.g.
Eric W. Biederman wrote:
_00FD_FC00_h - _00FD_FDFF_h On a hypertransport based
system should work. There is a 32MB window for it.
It doesn't. The termination on MMIO and IOIO transaction is different,
and poking this memory window with an MMIO transaction will lock the
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
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
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
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
Eric W. Biederman wrote:
_00FD_FC00_h - _00FD_FDFF_h On a hypertransport based
system should work. There is a 32MB window for it.
It doesn't. The termination on MMIO and IOIO transaction is different,
and poking this memory window with an MMIO transaction will lock the
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, and whether
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, and whether
> The obvious thing to do would be to hook it up like:
> drivers/pci/proc.c:proc_bus_pci_ioctl.
Yes that is what it intended to do -- i just had never finished/tested
that.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
The obvious thing to do would be to hook it up like:
drivers/pci/proc.c:proc_bus_pci_ioctl.
Yes that is what it intended to do -- i just had never finished/tested
that.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Thu, Dec 13, 2007 at 04:35:05PM -0800, David Miller wrote:
> From: Greg KH <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 16:19:32 -0800
>
> > On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
> > > Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
> > >
Greg KH <[EMAIL PROTECTED]> writes:
> On Thu, Dec 13, 2007 at 08:59:44PM -0700, Eric W. Biederman wrote:
>> [EMAIL PROTECTED] writes:
>>
>> > Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
>> >
>> > TBD: Do we need the ioctl interface to sysfs or get the type
On Thu, Dec 13, 2007 at 08:59:44PM -0700, Eric W. Biederman wrote:
> [EMAIL PROTECTED] writes:
>
> > Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
> >
> > TBD: Do we need the ioctl interface to sysfs or get the type attribute
> > through a different sysfs file. And
[EMAIL PROTECTED] writes:
> Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
>
> TBD: Do we need the ioctl interface to sysfs or get the type attribute
> through a different sysfs file. And then actually specify the attribute
> while doing pci_mmap_page_range ;-)
This
On Thursday, December 13, 2007 3:55 pm [EMAIL PROTECTED] wrote:
> Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
>
> TBD: Do we need the ioctl interface to sysfs or get the type attribute
> through a different sysfs file. And then actually specify the attribute
> while
On Thu, Dec 13, 2007 at 04:19:32PM -0800, Greg KH wrote:
> On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
> > Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
> >
> > TBD: Do we need the ioctl interface to sysfs or get the type attribute
> > through a
From: Greg KH <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 16:19:32 -0800
> On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
> > Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
> >
> > TBD: Do we need the ioctl interface to sysfs or get the type
On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
> Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
>
> TBD: Do we need the ioctl interface to sysfs or get the type attribute
> through a different sysfs file. And then actually specify the attribute
>
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a different sysfs file. And then actually specify the attribute
while doing pci_mmap_page_range ;-)
And when this interface is in place, X
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a different sysfs file. And then actually specify the attribute
while doing pci_mmap_page_range ;-)
And when this interface is in place, X
On Thu, Dec 13, 2007 at 04:19:32PM -0800, Greg KH wrote:
On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a
On Thursday, December 13, 2007 3:55 pm [EMAIL PROTECTED] wrote:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a different sysfs file. And then actually specify the attribute
while doing
On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a different sysfs file. And then actually specify the attribute
while
From: Greg KH [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 16:19:32 -0800
On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
[EMAIL PROTECTED] writes:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a different sysfs file. And then actually specify the attribute
while doing pci_mmap_page_range ;-)
This ioctl
On Thu, Dec 13, 2007 at 08:59:44PM -0700, Eric W. Biederman wrote:
[EMAIL PROTECTED] writes:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a different sysfs file. And then
Greg KH [EMAIL PROTECTED] writes:
On Thu, Dec 13, 2007 at 08:59:44PM -0700, Eric W. Biederman wrote:
[EMAIL PROTECTED] writes:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do we need the ioctl interface to sysfs or get the type attribute
through a
On Thu, Dec 13, 2007 at 04:35:05PM -0800, David Miller wrote:
From: Greg KH [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 16:19:32 -0800
On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote:
Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree.
TBD: Do
32 matches
Mail list logo
