>>> - FAA_MMREG_BAR may contain the beginning address of a space to be >>> mapped. But how does `pci_mapreg_map' know the extension of such >>> a map? >> [...], the BAR contains all info needed (or should, if setup has >> worked correctly). > Oh, ok, so the BAR does not specify just an address: it also > specifies the extension of the memory space. I could not guess this.
Guessing should not be relevant; how BARs work is part of the PCI definition. I forget details, but I think things like "I/O mapping versus memory mapping" are present in read-only bits at the LSB end of the BAR. NetBSD has a bunch of #defines for them; look for PCI_MAPREG_ in pcireg.h - or, at least, that's where they are on 1.4T, 5.2, and 8.0; while I don't have anything more recent at ready hand to check, I'd guess that something that stable is probably going to stay stable. >> Give this is mips I assume PCI_MAPREG_TYPE_MEM is correct, but for a >> new device you may be unsure, and sometimes variants of devices >> exist that either make the type IO or MEM. You can query that in >> your driver with pci_mapreg_info() - but for the concrete case the >> userland pcictl output is easier. > Consider that this is a custom PCI device, created by the author of > the tutorial as statement in the sourcecode of gxemul [...] In this particular case, sure; I suspect the person who wrote the double-quoted text above was trying to give advice applicable beyond the case at immediate hand. > Looking into the output of pcictl(8), also `I/O space accesses: on' > is on, but I don't know if it is significant. PCI is defined to have two address spaces, called I/O space and memory space. On x86, these normally correspond to I/O instructions (inb/outb/etc) and memory-mapped I/O, respectively. On other machines, this often works differently; some PCI attachments present PCI I/O space as memory-mapped too, just in a different part of the address space. (I daresay this could be done on x86 too, if a chipset/board maker wanted to, but it would render the hardware incompatible with a lot of OS code, so it's not normally done.) The line you cite > Command register: 0x0003 > I/O space accesses: on is a PCI thing, indicating that the device is configured to respond to a PCI access marked as an I/O space access, provided it's mapped by a suitable mapping register. If the hardware is something that doesn't have separate I/O space instructions, then PCI I/O space probably turns into something else from the CPU's point of view, like a different part of the address space, or some other way of marking accesses as being in a different address space (like SPARC's lda and sta instructions, which take an address-space identifier as well as an address). For a machine that already has a NetBSD port supporting PCI, those details should already be handled for you by the bus_space implementation for that port. Your driver just needs to know "is this a (PCI) I/O space mapping or a (PCI) memory space mapping?", and sometimes not even that; what it turns into at the machine-code level is hidden by the bus_space layer. See pci_mapreg_type(), pci_mapreg_map(), etc. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
