At 5:01 PM -0600 3/6/2001, Oliver Xymoron wrote:
>On Fri, 2 Mar 2001, David S. Miller wrote:
>
>> > On PPC, we don't have an "IO" space neither, all we have is a range of
>> > memory addresses that will cause IO cycles to happen on the PCI bus.
>>
>> This is precisely what the "next MMAP is XXX
On Fri, 2 Mar 2001, David S. Miller wrote:
> > On PPC, we don't have an "IO" space neither, all we have is a range of
> > memory addresses that will cause IO cycles to happen on the PCI bus.
>
> This is precisely what the "next MMAP is XXX space" ioctl I've
> suggested is for. I think I've
On Fri, 2 Mar 2001, David S. Miller wrote:
On PPC, we don't have an "IO" space neither, all we have is a range of
memory addresses that will cause IO cycles to happen on the PCI bus.
This is precisely what the "next MMAP is XXX space" ioctl I've
suggested is for. I think I've addressed
[EMAIL PROTECTED] said:
> You can map and unmap for each call :) Ugly and slow, but hey, it's
> I/O...
outb(bus *bus, u8 val, u16 addr);
#ifdef ONE_TRUE_BUS_SPACE
#define outb(bus, val, addr) __outb(val, addr)
#else
#define outb(bus, val, addr) bus->out8(bus, val, addr)
#endif
--
[EMAIL PROTECTED] said:
You can map and unmap for each call :) Ugly and slow, but hey, it's
I/O...
outb(bus *bus, u8 val, u16 addr);
#ifdef ONE_TRUE_BUS_SPACE
#define outb(bus, val, addr) __outb(val, addr)
#else
#define outb(bus, val, addr) bus-out8(bus, val, addr)
#endif
--
>I/O is not supposed to be fast, that's what MMIO is for. :) Just do
>
>void outb (u8 val, u16 addr)
>{
> void *addr = ioremap (ISA_IO_BASE + addr);
> if (addr) {
> writeb (val, addr);
> iounmap (addr);
> }
>}
>
>You can map and unmap for each call
Benjamin Herrenschmidt wrote:
>
> >No, don't do this, it is evil. Use mappings, specify the device
> >related info somehow when creating the mapping (in the userspace
> >variant you do this by openning a specific device to mmap, in the
> >kernel variant you can encode the bus/dev/etc. info in
>No, don't do this, it is evil. Use mappings, specify the device
>related info somehow when creating the mapping (in the userspace
>variant you do this by openning a specific device to mmap, in the
>kernel variant you can encode the bus/dev/etc. info in the device's
>resource and decode this at
No, don't do this, it is evil. Use mappings, specify the device
related info somehow when creating the mapping (in the userspace
variant you do this by openning a specific device to mmap, in the
kernel variant you can encode the bus/dev/etc. info in the device's
resource and decode this at
Benjamin Herrenschmidt wrote:
No, don't do this, it is evil. Use mappings, specify the device
related info somehow when creating the mapping (in the userspace
variant you do this by openning a specific device to mmap, in the
kernel variant you can encode the bus/dev/etc. info in the
I/O is not supposed to be fast, that's what MMIO is for. :) Just do
void outb (u8 val, u16 addr)
{
void *addr = ioremap (ISA_IO_BASE + addr);
if (addr) {
writeb (val, addr);
iounmap (addr);
}
}
You can map and unmap for each call :) Ugly and
Benjamin Herrenschmidt writes:
> There is still the need, in the ioctl we use the "select" what need to be
> mapped by the next mmap, to ask for the "legacy IO range of the bus where
> the card reside" (if it exist of course). That would be the 0-64k (or less,
> actually a couple of pages
Benjamin Herrenschmidt writes:
> What I call ISA IOs here doesn't necessarily mean there's an ISA bridge
> on the PCI.
Ok.
> On PPC, we don't have an "IO" space neither, all we have is a range of
> memory addresses that will cause IO cycles to happen on the PCI bus.
This is precisely what
"David S. Miller" wrote:
> There is another case you are ignoring. Some devices support memory
> space as well as I/O space, but only operate reliably when their
> I/O space window is used to access it.
ok. Those also fall into the category of "I personally don't care" :^)
> It just sounds to
>I do not want an interface where the user still has to do
>grotty stuff like mmap() on /dev/{mem,kmem}, this was the
>core of the problem I had with the syscall idea, don't bring
>it back.
>
>Make mmap()'s on a PCI-->ISA bridge do something special, for
>example.
>
>The user doesn't need to know
>Many platforms, sparc64 included, do not have an ISA IO space nor do
>they provide VGA accesses at all.
>
>If things such as XFree86 are coded for such platforms to not require
>VGA accesses (the 'ati' driver is already like this when certain
>build time defines are set), this could become a
I do not want an interface where the user still has to do
grotty stuff like mmap() on /dev/{mem,kmem}, this was the
core of the problem I had with the syscall idea, don't bring
it back.
Make mmap()'s on a PCI--ISA bridge do something special, for
example.
The user doesn't need to know anything
"David S. Miller" wrote:
There is another case you are ignoring. Some devices support memory
space as well as I/O space, but only operate reliably when their
I/O space window is used to access it.
ok. Those also fall into the category of "I personally don't care" :^)
It just sounds to me
Benjamin Herrenschmidt writes:
What I call ISA IOs here doesn't necessarily mean there's an ISA bridge
on the PCI.
Ok.
On PPC, we don't have an "IO" space neither, all we have is a range of
memory addresses that will cause IO cycles to happen on the PCI bus.
This is precisely what the
Benjamin Herrenschmidt writes:
There is still the need, in the ioctl we use the "select" what need to be
mapped by the next mmap, to ask for the "legacy IO range of the bus where
the card reside" (if it exist of course). That would be the 0-64k (or less,
actually a couple of pages would
Grant Grundler writes:
> A nice side effect of this bloat is it will discourage use of I/O
> Port space. That's good for everyone, AFAICT. (I know some devices
> *only* support I/O port space and I personnally don't care about
> them. If someone who does care about one wants to talk to me
Benjamin Herrenschmidt wrote:
> Hi Grant !
>
> Alan Cox suggested I contact you about this. I'm trying to figure out a
> way to cleanly resolve the problem of doing IO accesses on machines with
> multiple PCI host bridges (and multiple IO bases when IO cycles are not
> generated by the CPU).
> There is no 'fake' ISA bus number you need. There is a 'real' one,
> the one on which the PCI-->ISA bridge lives, why not use that one
> :-)
IFF the ISA bus hangs off the PCI bridge. Similarly not all machines have
PCI as the primary I/O bus. On hppa PCI busses hang off the gsc bus
-
To
Benjamin Herrenschmidt writes:
> Also, an ioctl to retreive the iobase would be useful too
No, the whole point of my suggested mmap() interface is to
_ENTIRELY_ eliminate any reason for the user to even see
what the physical addressing of the machine looks like.
If you start pushing iobases
Dan Malek writes:
> It actually caused me to think of something elseI have cards
> with multiple memory and I/O spaces (rare, but I have them).
So what? All such bar's within mem/io space are part of unique
regions of the total MEM/IO space.
Thus you can pass non-conflicting offset/size
Benjamin Herrenschmidt writes:
> Also, the problem of finding where the legacy ISA IOs of a given PCI bus
> are is a bit different that simply mmap'ing a BAR. Some video cards
> require some access to their VGA IOs without having a BAR covering them,
> in some case it's necessary to switch
>As a side note, Alpha has a special PCI syscall to get the "PCI
>controller number" a given PCI device is behind. We could add
>another ioctl number which does the same thing on /proc/bus/pci/*/*
>nodes. This way sparc64 and Alpha could have the same user visible
>API for this as well.
And on
"David S. Miller" wrote:
> There is only one sticking point, and that is how to convey to the
> mmap() call whether you want I/O or Memory space.
Isn't I/O space obsolete by now :-)? It actually caused me to think
of something elseI have cards with multiple memory and I/O
spaces (rare, but
> > I'm, of course open to any comments about this (in fact, I'd really like
> > some feedback). One thing is that we also need to find a way to pass
> > those infos to userland. Currently, we implement an arch-specific syscall
> > that allow to retreive the IO physical base of a given PCI bus.
Dan Malek writes:
> "David S. Miller" wrote:
>
> > I played around with something akin to this, and some of the necessary
> > Xfree86-4.0.x hackery needed, some time ago. But I never finished
> > this.
>
> Sounds pretty sweet. How about we finish it? Any complaints (well
>
"David S. Miller" wrote:
> I played around with something akin to this, and some of the necessary
> Xfree86-4.0.x hackery needed, some time ago. But I never finished
> this.
Sounds pretty sweet. How about we finish it? Any complaints (well
reasonable ones :-) or concerns that came out of
Benjamin Herrenschmidt writes:
> I'm, of course open to any comments about this (in fact, I'd really like
> some feedback). One thing is that we also need to find a way to pass
> those infos to userland. Currently, we implement an arch-specific syscall
> that allow to retreive the IO
> I'm, of course open to any comments about this (in fact, I'd really like
> some feedback). One thing is that we also need to find a way to pass
> those infos to userland. Currently, we implement an arch-specific syscall
> that allow to retreive the IO physical base of a given PCI bus. That may
>
>If we want to go a bit further, and allow ISA drivers that don't have a
>pci_dev structure to work on legacy devices on any bus, we could provide
>a set of function of the type
>
> int isa_get_bus_count();
> unsigned long isa_get_bus_io_offset(int busno);
I would add that I'd prefer to keep
If we want to go a bit further, and allow ISA drivers that don't have a
pci_dev structure to work on legacy devices on any bus, we could provide
a set of function of the type
int isa_get_bus_count();
unsigned long isa_get_bus_io_offset(int busno);
I would add that I'd prefer to keep it
I'm, of course open to any comments about this (in fact, I'd really like
some feedback). One thing is that we also need to find a way to pass
those infos to userland. Currently, we implement an arch-specific syscall
that allow to retreive the IO physical base of a given PCI bus. That may
be
Dan Malek writes:
"David S. Miller" wrote:
I played around with something akin to this, and some of the necessary
Xfree86-4.0.x hackery needed, some time ago. But I never finished
this.
Sounds pretty sweet. How about we finish it? Any complaints (well
reasonable ones :-)
Benjamin Herrenschmidt wrote:
Hi Grant !
Alan Cox suggested I contact you about this. I'm trying to figure out a
way to cleanly resolve the problem of doing IO accesses on machines with
multiple PCI host bridges (and multiple IO bases when IO cycles are not
generated by the CPU). I'd be
As a side note, Alpha has a special PCI syscall to get the "PCI
controller number" a given PCI device is behind. We could add
another ioctl number which does the same thing on /proc/bus/pci/*/*
nodes. This way sparc64 and Alpha could have the same user visible
API for this as well.
And on PPC
Benjamin Herrenschmidt writes:
Also, the problem of finding where the legacy ISA IOs of a given PCI bus
are is a bit different that simply mmap'ing a BAR. Some video cards
require some access to their VGA IOs without having a BAR covering them,
in some case it's necessary to switch the
I'm, of course open to any comments about this (in fact, I'd really like
some feedback). One thing is that we also need to find a way to pass
those infos to userland. Currently, we implement an arch-specific syscall
that allow to retreive the IO physical base of a given PCI bus. That may
There is no 'fake' ISA bus number you need. There is a 'real' one,
the one on which the PCI--ISA bridge lives, why not use that one
:-)
IFF the ISA bus hangs off the PCI bridge. Similarly not all machines have
PCI as the primary I/O bus. On hppa PCI busses hang off the gsc bus
-
To
Benjamin Herrenschmidt writes:
I'm, of course open to any comments about this (in fact, I'd really like
some feedback). One thing is that we also need to find a way to pass
those infos to userland. Currently, we implement an arch-specific syscall
that allow to retreive the IO physical
Dan Malek writes:
It actually caused me to think of something elseI have cards
with multiple memory and I/O spaces (rare, but I have them).
So what? All such bar's within mem/io space are part of unique
regions of the total MEM/IO space.
Thus you can pass non-conflicting offset/size
Grant Grundler writes:
A nice side effect of this bloat is it will discourage use of I/O
Port space. That's good for everyone, AFAICT. (I know some devices
*only* support I/O port space and I personnally don't care about
them. If someone who does care about one wants to talk to me about
"David S. Miller" wrote:
There is only one sticking point, and that is how to convey to the
mmap() call whether you want I/O or Memory space.
Isn't I/O space obsolete by now :-)? It actually caused me to think
of something elseI have cards with multiple memory and I/O
spaces (rare, but I
Benjamin Herrenschmidt writes:
Also, an ioctl to retreive the iobase would be useful too
No, the whole point of my suggested mmap() interface is to
_ENTIRELY_ eliminate any reason for the user to even see
what the physical addressing of the machine looks like.
If you start pushing iobases to
"David S. Miller" wrote:
I played around with something akin to this, and some of the necessary
Xfree86-4.0.x hackery needed, some time ago. But I never finished
this.
Sounds pretty sweet. How about we finish it? Any complaints (well
reasonable ones :-) or concerns that came out of
48 matches
Mail list logo
