Actually, it occurs to me that there is an easier way:

PCI_MAPREG_TYPE_ROM could be defined the same as PCI_MAPREG_TYPE_MEM,
and the PCI register mapping code could look at the offset of the register.

PCI_MAPREG_ROM is *always* 0x30.  That's probably a better way to do it.

Please consider that my current proposal. :-)

    -- Garrett

Garrett D'Amore wrote:
> The pci_mapreg_map() manual page indicates that you can map a ROM using
> PCI_MAPREG_TYPE_ROM.
>
> Currently this won't work.  There is no PCI_MAPREG_TYPE_ROM macro defined.
>
> I'd like to first propose that we fix this.  I'm volunteering to do it.
>
> The next problem is that PCI_MAPREG_TYPE_ROM needs to have a value
> assigned to it.  This is where it gets sticky:
>
> 1) Currently all other PCI_MAPREG_TYPE_xxx values correspond to actual
> values that can be placed in a BAR (base address register).   (This
> includes btw,  PCI_MAPREG_ROM_ENABLE)
>
> 2) The ROM BAR at 0x30 has a different definition for which bits it can
> use.  E.g. bit 0 in the ROM bar enables the address decoder, whereas in
> an IO/Memory bar it indicates that the BAR is for IO address decoding.
>
> 3) There are no "unused" bits for me to use and stay within the current
> defined bit patterns for PCI BARs.
>
>
> Okay, so my *proposal* here is to use an illegal ("reserved") bit
> pattern for PCI_MAPREG_TYPE_MEM and call it PCI_MAPREG_MEM_TYPE_ROM,
> that pattern will be 0x6.  If you look in the PCI specs, that pattern is
> not legal for a memory address decoder.
>
> The second bit is that I will create PCI_MAPREG_TYPE_ROM that will be
> defined as PCI_MAPREG_TYPE_MEMORY | PCI_MAPREG_MEM_TYPE_ROM.
>
> I think will add the necessary logic to handle this all properly.
>
> The ugliness from this stems that I'll be leveraging the PCI_MAPREG_TYPE
> field in an "inconsistent" way because those bits will never get passed
> as is to the device.
>
> The only other solutions I can see to this are to
>
> a) create another argument to pci_mapreg_map() that indicates the
> mapping register type *separately* from the address decoder bits,
>
> b) create a "switch" table where the pci mapreg_map() argument is not
> necessarily the same as the bits in the PCI registers, or
>
> c) create some new function, pci_mapreg_map_rom() or somesuch, that does
> the right thing without disrupting anything else, and change the
> documentation to reflect this (and change the documentation to match)
>
> Hopefully this isn't another bikeshed. :-)
>
>     - Garrett
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191