Re: pci_mapreg_map and BAR from `Bus space tutorial'

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> - 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B