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 add
[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 th
>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 i
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 wou
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 m
>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 non-
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 abo
t; generated by the CPU). I'd be glad if you could catch on the
> "The IO problem on multiple PCI busses" thread on linux-kernel list
> and let us share your point of viw.
To l-k, Benjamin wrote:
| I've looked at the parisc code (thanks Alan for pointing that out), and
|
> 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 unsub
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
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 th
>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. Th
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
"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 disc
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
> 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 it
Here's the return of an ld problem for which we really need a
solution asap since it's now biting us in real life configurations...
So the problem happens when you have a machine with more than one PCI
host bridge. This is typically the case of all new Apple machines as they
have 3 host bridg
26 matches
Mail list logo
