HI Michael,

> > 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? 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.

> > The thing to keep in mind is that there is not an exact correlation
> > between the PCI spec and the Open Firmware implementation. During
> > discovery process, work with OF and compensate for bugs. Then use
> > that information to deal with PCI.
> 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

reg          
          00015800 00000000 00000000 00000000 00000000 
          02015818 00000000 00000000 00000000 04000000 
          02015814 00000000 00000000 00000000 00001000

assigned-addresses      
          82015814 00000000 94000000 00000000 00001000 
          82015818 00000000 90000000 00000000 04000000


The 1581x part is the PCI device tag. The 158 part is
actually three combined values that span bytes (bus,
device and function), and the 1x is the base register. To determine the
three values, it is easiest to look at pci_machdep.c for how to
decompose one:

void
pci_decompose_tag(pc, tag, bp, dp, fp)
        pci_chipset_tag_t pc;
        pcitag_t tag;
        int *bp, *dp, *fp;
{

        if (bp != NULL)
                *bp = (tag >> 16) & 0xff;
        if (dp != NULL)
                *dp = (tag >> 11) & 0x1f;
        if (fp != NULL)
                *fp = (tag >> 8) & 0x07;
}

so bus = 1, dev = 58 & 1f = 16, and function = 0. The PCI tag for 15800
points to /chaos/control. That's the bridge between identifying the PCI
device with the Open Firmware node, which is already in autoconf.c

int
pcidev_to_ofdev(pc, tag)

> > 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? What are the
assigned-addresses for the node, and what are the properties for your
video on your S900?

>>There are some built in tags
> > that should use memory space instead of I/O, and it'd be a good idea
> > to stay consistent with those for the macppc port.

That should read "tags that (say) say use memory space."

> Yes, that's all nice and true and such, but it doesn't really help
> with the X11 problem. To make it abundantly clear: there is no way
> around IO space to access certain registers on certain VGA-compatible
> graphics boards, like almost all PCI and AGP cards, and if memory
> mapped IO can be used depends on the XFree driver, some know how to
> access memory-mapped registers, some don't. Instead of fixing all the
> drivers and probably breaking things on other platforms I think it's
> way more sensible to provide something that allows them to run
> unchanged, which is exactly what my patches do. But apparently we're
> talking about different things again :P

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 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.
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).

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. Getting a video card with I/O space to
run X strikes me as not true support for the hardware. (That being said,
I have only run NetBSD as a serial and ssh console, so I have not run X
on either box.)

However, and this is how come we're figuring the other person knows more
about this, I don't know much if anything about VGA. I was trying to
show what I see from the OF perspective when it initializes devices and
where things are in 32 bit address space. 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.
Quite the opposite, which is why I took so long to compose the first
email, in order to at least establish common perspective. I posted to
the list in order to let anyone else interested in learning about it
have material on something that can be quite arcane and mind-bending.

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."

tim