| On Mon, Jan 21, 2002 at 06:38:12PM +0100, Martin Husemann wrote:

| > I then could configure it, but it needs major changes to even be able
| > to compile on sparc64.
| > 
| > All the reg{r/w}[b] routines need a rewrite, based on bus_spac_*
| > functions. The use of u_int32_t in this context is, of course,
| > highly 32 bit specific.
|
| This is the place where I didn't understand how the linear mapping
| works on non-x86 architecture.

Linear mappings are only needed if you plan to use bus_space_vaddr()
and do direct memory accesses instead of using bus_space_{read,write}*().
Using linear mappings limits you to instances where the ranges can be
accessed with normal memory accesses.  But, if the device cannot be
accessed that way and needs a special instruction coding, the driver
will not work.

| And the reason why I used u_int32_t was the following code in
| vga_pci.c:
|
| 		if (PCI_MAPREG_MEM_TYPE(psc->sc_bars[bar].vb_type) ==
| 		    PCI_MAPREG_MEM_TYPE_64BIT) {
| 			/* XXX */
| 			printf("%s: WARNING: ignoring 64-bit BAR @ 0x%02x\n",
| 			    sc->sc_dev.dv_xname, reg);
| 			continue;
| 		}
|
| Does NetBSD support 64 bit PCI I/O? Or is it possible to use 64 bit
| capable cards on 32 bit machines?

64-bit PCI support is only required if you need 64-bit addressing.
So, unless your device needs more than a few hundred megs of PCI
address space or needs to do direct I/O to a machine with a 64-bit
address space, you don't need 64-bit PCI.

64-bit accesses are comppletely different issue.  They should be
completely transparent to the hardware, and in fact it should be
possible for a write combining memory controller to combine a
series of small adjacent memory operations into a single 64-bit
PCI bus transaction.

I suppose 64-bit transactions are really only significant when
using the CPU for bitblits, where bandwidth is really important.

Eduardo