> I'm using pci_mapreg_map() to map the chip's RAM, passing it
> PCI_MAPREG_TYPE_MEM | PCI_MAPREG_MEM_TYPE_32BIT for the "expected"
> argument. This gets me a tag and handle that I can use with the
> bus_space_* macros/functions to access the memory. However, the driver
> wants to be able to access the memory as a struct, and do stuff like
> "scriptstruct->member = somevalue".

"so, fix it."  That is not portable code.  Device memory may not be
mapped linearly, and indeed on many systems _is not_ mapped inearly.

Do you know off-hand whether the mapping registers say that the region
is prefetchable or not?  (I'm just wondering for my own curiosity; it
doesn't affect anything i've said here.)


> I could use the bus_space_write*
> macros, but that kinda seems like it'd make the code harder to read,

No, it makes the code _correct_, not harder to read.

Code that isn't correct is useless (if what you want to do is use it
successfully 8-), regardless of how easy to read it is.


> so I'm wondering if it's possible to get a virtual address out of the
> tag and handle that I can assign to a pointer.

You can't.  There's no necessary correspondence between handle
representation and virtual address, and even if there were, as i said,
the memory may not be mapped linearly.  (I can easily imagine
cases/systems where you might want and be able to to access memory in
such a way that it's not even mapped into kernel VA space.)


> As a workaround, I'm just using the bus_space_handle_t that I get back
> as the pointer to the memory (since at least on the i386, that's what
> it is), but this is probably not a good MI thing to be doing :)

That is _not_ a good MI thing to be doing, and isn't even a
particularly good MD thing to be doing.


cgd