Hello,

> > > As far as using I/O or memory space on PowerPC PCI, it's just easier
> > > to use the memory space directly.
> > I know. But the problem with X is that it wants to use the VGA
> > registers on VGA-compatible hardware so we NEED to access IO space. On
> > my S900 that works like a charm. 
> 
> Correct me if I'm wrong, but isn't your S900 using a PCI video card?
Yes.

> As I showed in the previous email, there is no I/O register in
> /chaos/control, but it can be trained to be VGA-like.
Yes, sure. Most VGA cards can do that ( my Voodoo3 replicates the VGA registers in an IO range, not sure about memory ) - but the point is that
- not all VGA cards (can) do that
- not all XFree86 drivers would use it. Some insist on IO space ( like apparently the ATi driver )

> > Well, I never bothered with that directly - the information how to
> > access PCI IO space is encoded into the pa_iot member of struct
> > pci_attach_args. That's what I use and so far it works.
> 
> Let me re-use the /chaos/control device as a clarification:
> 
> ff83f9d8: /chaos@f0000000/control@15800,0,0
...
> The 1581x part is the PCI device tag.
Ok, my clarification - I didn't mean the device tag but the bus_space tag for the IO range.

> > > Don't use the I/O, use the memory space.
> > You don't always have a choice. The DEC 21140 on my E100 board offers
> > both, memory and IO - and both work, it defaults to memory though. A
> > cheap NE2000 lookalike offers only IO - works fine for me.
> 
> The NE2000 works on Apple/clone hardware?
Yes. The RealTek 8029 is a NE2000 clone, I tried it just for fun and it worked just fine.

> What are the assigned-addresses for the node
Can't look that up right now, the card isn't built-in right now and the box is busy.
As far as I remember it only needs a 256 byte IO range and an interrupt.

> and what are the properties for your video on your S900?
ff8476d0: /bandit@f2000000/3Dfx,Voodoo3@e

vendor-id               0000121a ........ ........ ........   ....
device-id               00000005 ........ ........ ........   ....
revision-id             00000001 ........ ........ ........   ....
class-code              00030000 ........ ........ ........   ....
interrupts              00000001 ........ ........ ........   ....
min-grant               00000000 ........ ........ ........   ....
max-latency             00000000 ........ ........ ........   ....
subsystem-vendor-id     0000121a ........ ........ ........   ....
subsystem-id            00000005 ........ ........ ........   ....
devsel-speed            00000000 ........ ........ ........   ....
fast-back-to-back       
AAPL,interrupts         00000018 ........ ........ ........   ....
AAPL,slot-name          423100.. ........ ........ ........   B1.
fcode-rom-offset        00000000 ........ ........ ........   ....
base0                   00000000 ........ ........ ........   ....
base1                   00000008 ........ ........ ........   ....
base2                   00000001 ........ ........ ........   ....
name                    33446678 2c566f6f 646f6f33 00......   "3Dfx,Voodoo3"
reg                     00007000 00000000 00000000 00000000   ..p.............
            0010:       00000000 02007010 00000000 00000000   ......p.........
            0020:       00000000 02000000 02007014 00000000   ..........p.....
            0030:       00000000 00000000 10000000 01007018   ..............p.
            0040:       00000000 00000000 00000000 00000100   ................
            0050:       02007030 00000000 00000000 00000000   ..p0............
            0060:       00010000 ........ ........ ........   ....
device_type             64697370 6c617900 ........ ........   "display"
model                   566f6f64 6f6f3320 32303030 00......   "Voodoo3 2000"
character-set           49534f38 3835392d 3100.... ........   ISO8859-1.
width                   00000280 ........ ........ ........   ....
height                  000001e0 ........ ........ ........   ....
depth                   00000008 ........ ........ ........   ....
linebytes               00000280 ........ ........ ........   ....
iso6429-1983-colors     
driver,AAPL,MacOS,PowerPC
power-consumption       00000000 00000000 ........ ........   ........
assigned-addresses      81007018 00000000 00001000 00000000   ..p.............
            0010:       00000100 82007030 00000000 88000000   ......p0........
            0020:       00000000 00010000 82007010 00000000   ..........p.....
            0030:       86000000 00000000 02000000 82007014   ..............p.
            0040:       00000000 90000000 00000000 10000000   ................
base0-open              86000000 ........ ........ ........   ....
base1-open              90000008 ........ ........ ........   ....
base2-open              00001001 ........ ........ ........   ....
address                 90000000 ........ ........ ........   ....

> We do tend to find we're talking about different things, but I know
> without a doubt that you know what you're talking about :-)
I wouldn't be too sure about that :)

> I guess there were two points to my post. One was to show the machine
> dependent layer tie-in with the PCI code, and to show that the Apple PCI
> implementation does not behave the same as the PC PCI implementation.
That's without any doubt the case, at least for OldWorld machines. Accessint IO ranges would be extremely difficult if it weren't.

> Neither are wrong, they are just different and that's why a lot of
> PC-centric cards and code doesn't work exactly on Apple hardware (I
> didn't even broach endian issues :-), and sometimes the hardware just
> flat out needs a macppc specific driver to work (though not often, much
> to the credit of the device drivers writers).
XFree has some sort of abstraction layer that takes care of endianness and register access. The main problem was that user space programs have no easy way to figure out how to access PCI IO registers - having the Xserver scan bandit, grackle and the like is unacceptable, especially since the kernel has a working abstraction scheme. You can easily replace all the IO instructions and make them memory accesses ( which is standard on PowerPC ) - the only missing thing was to provide the right address range so register accesses really accessed registers and not just some memory.

> The other point was to show that dependency on I/O space for VGA could
> have problems if the Mac doesn't have I/O space for their display, as is
> the case for my 7600 and 7300.
I'm not at all concerned with Macintosh onboard video, as far as I know XFree doesn't really support them anyway, if it does it won't need my patches ( because no one would need access to any IO range ). The VGA stuff is needed because 
- most PCI and AGP graphics cards are VGA compatible and
- most XFree drivers use the VGA registers or have another IO range so we better make sure they can do that.

> Getting a video card with I/O space to
> run X strikes me as not true support for the hardware. 
Somehow I don't get what you're trying to say - why should that be 'not true support' ?

> It seemed to me that
> dependency on I/O space for macppc is not a good idea, but that in no
> way means I'm critical of your patches or the effort you've done.
No problem, the patches are well worth of criticism, the method I use right now may cause weird problems in certain situations...

> If I am missing a component of understanding that allows I/O space to be
> used when there isn't one that I see in OF, then I want to fill in that
> blank.  My hope was along the lines of "it might work if you do the same
> thing in memory space since it often fixes problems with PC technology
> running on Apple hardware."
I guess on Apple hardware you just have to know where the IO range of any given PCI bus is mapped into memory - at least that's what Apple's documentation suggests. Of course using memory ranges is more straight forward but the IO stuff is in the PCI specification, devices use it so we better support it properly.