On Thu 18 Dec 1997, maximum entropy wrote:
> >From: Jason Thorpe <thorpej@nas.nasa.gov>
> >
> >On Wed, 17 Dec 1997 22:58:45 +0100 
> > Leo Weppelman <leo@wau.mis.ah.nl> wrote:
> >
> > > I was more or less hoping I missed something. That extra copy bothers
> > > me.
> >
> >Um, bus_space_map() with the "linear" flag should make this work OK.  Also,
> >if you make this a machine-dependent driver, we can get by until
> >bus_space_mmap() is implemented.
> 
> Yes, the code maps the framebuffer memory
> BUS_SPACE_MAP_LINEAR|BUS_SPACE_MAP_CACHEABLE, and the uiomove() does
> in fact do the right thing.  What's broken about it (and what I think
> Leo is complaining about) isn't that it doesn't work, but rather that
> the driver needs to know too much about the MD meanings of the
> bus_space types, which should be opaque.

Exactly. The code fragment adds a few opaque values to obtain an address
argument for uiomove() - this is the 'obviously wrong' part. This part ceases
to work when I add stuff to the tag that's needed to determine if the bus
endianness is not matching the endianness of the cpu. This endianness is
also the tricky part here. This is probably not solved by mapping the frame
buffer - at least I can't see how.

> I'd like to hear more about bus_space_mmap(), it sounds like that
> might be what we're looking for.
> 
> >Why use read/write?  mmap is your friend!
> 
> Because it's there, mostly.  The driver does have an mmap entry point
> as well.

Yup. Also the mmap interface might be even impossible to provide because
of the endian conversion required or a sparse mapping as Mike suggests.

Note that I have written this with the assumption that a bus has certain
endianness and that cpu<->bus conversion should be handled by the
bus-functions.

Leo.