tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pci_mapreg_map and BAR from `Bus space tutorial'



On Mon, Jun 01, 2020 at 08:35:13PM +0200, Rocky Hotas wrote:
>         pci_aprint_devinfo(pa, NULL);
> 
>         if (pci_mapreg_map(pa, FAA_MMREG_BAR, PCI_MAPREG_TYPE_MEM, 0, 
>             &sc->sc_regt, &sc->sc_regh, &sc->sc_reg_pa, 0) != 0 ) {
>             aprint_error_dev(sc->sc_dev, "can't map the BAR\n");
>             return;
>         }
> 
>         aprint_normal_dev(sc->sc_dev, "regs at 0x%08x\n", (uint32_t)
> sc->sc_reg_pa);
> }
> 
> IIUC from the slides and the manpages, `pci_mapreg_map' (PCI-specific
> way of mapping a memory space) invokes `bus_space_map' (generic
> bus_space way of mapping a memory space).
> 
> My doubts are:
> 
> - What does exactly do `pci_mapreg_map'? Does it map the physical address
>   contained in FAA_MMREG_BAR to a kernel virtual address?

Yes (and often creates a new MMU/pmap mapping for this)

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

It is just an offset (like a register number), the BAR contains all info
needed (or should, if setup has worked correctly).

If you remove your driver you can list the details from userland with
pcictl(8).

> - According to pci(9), the ``physical address of the mapping is in''
>   FAA_MMREG_BAR. But this assumes that someone previously wrote
>   FAA_MMREG_BAR with the physical address assigned to that specific PCI
>   device. As regards a NetBSD system, who knows that physical address
>   and who is supposed to write it on this PCI device's BAR, before it
>   can be used in `pci_mapreg_map'? That is: does the OS rely on the BIOS
>   configuration, or does the OS configure the BARs by itself?

Usually firmware (or early bootloaders) configure the BARs properly, but
sometimes they don't, and then NetBSD needs to run fixup code (which is
a kernel option and not included in most kernels). The output
of pcictl would help here.

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.

Martin


Home | Main Index | Thread Index | Old Index