I am trying to write a radeon framebuffer driver (ala machfb) -- yes I
have ATI's documentation, and yes the driver will be given back to
NetBSD.  The target for this driver is a MIPS processor.

However, it turns out that I really need to be able to access the
external PROM in order to extract some values from it for memory timing.

The question is how best to achieve this, especially given my MIPS
platform where I have to create an MMU entry to access the PCI memory bus.

The PCI configuration code doesn't treat this like an ordinary BAR
because for some devices external PROM access interferes with normal
device usage.  (Not a problem in the specific case of the radeon.)

I can see ways to do this, but I can't figure out which is the most
desirable, and am interested in hearing opinions, or better ideas if
anyone has any:

    1) Create a special PCI routine that does the work --
pci_map_extprom() or some such.  This would have to be supplied by the
port's PCI layer, and would do the appropriate MMU work to establish the
mapping(s).  There should also be a tear-down routine to release the
mapping.

    2) Create special pci_extprom_read() routine that works like
pci_conf_read only without endian swapping.  This is cleanest for my
platform, because I can reuse the same wired MMU entry that I'm using
for PCI configuration space.  Drawback is that it is slower, and you
can't use linear accesses (unless you copy into a scratch buffer first),
but does anyone care about that?  Second drawback is adding the code for
the other platforms.  I'm not interested in adding/testing this across a
zillion different ports.

    3) Same as number 2, but don't make it a MI interface, instead just
leave the mapping logic in a MD header.  This means radeonfb has to
#ifdef the usage.

    4) Modify my port's boot loader (aka BIOS) to export some
"properties" for the device.  This involves the least change to NetBSD,
but is not likely to be very reusable by anyone else.  It probably means
the radeon FB driver is not reusable  very easily, except on OpenBOOT
systems which already do this.

    5) Add port-specific logic to the radeonfb driver I'm writing that
does the MMU translations itself.  Surrounded by #ifdef's of course, 
And let someone else worry about porting it.  (The necessary mapping
code would be easy to write for i386, and for OBP systems you can just
grab properties out of OBP.)

My gut says that #2 is the best option, but it means adding a new PCI
interface.  I don't have enough experience with NetBSD to know how much
resistance there is likely to be to this, especially since it would
probably be a non-implemented API on most ports.

-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134