Eduardo Horvath <eeh@turbolinux.com> writes:
> > Fundamentally, it seems that what you're asking for, in these misnamed
> > bus_dmamem_*() macros, is for MD code to provide 'bus' macros to to
> > access memory in device-specific ways.
> 
> And the distinction is?  The point of the macros is to make the cpu access
> memory in the same manner as the device that will DMA it.

... and, for instance, PCI devices will always DMA in word-sized
quantities, or at the very least will always be doing transfers using
byte enables on a word-sized bus.

Is the right solution, then, that all accesses to PCI DMA memory
should be in 4-byte quantities?  (that would be fine with me, for PCI,
but would make programming more difficult, and would make it even
harder to make generic back-ends, as far as I can tell.)

BTW, you seem to have made the jump from "device supports swapping,"
to "controller supports swapping."  I'd argue that at least in the
controller-supports-swapping arena, controllers which do swapping in
a CPU-access-size-oriented manner (as your mmu seems to?) are in the
minority.

(I mean, heck, look even at lots of processors which support BE vs LE
modes; even they do it by modifying the memory address seemingly
touched in the other-endian accesses.)


> The precise
> wiring can vary depending on CPU, bus controller, and device.  The device
> driver should be able to explain to the bus_dma framework how it wants
> that set up and not have to worry about byte swapping itself.

Right; what you've proposed is one possible wiring, and one that seems
to me to be in the minority.


> Why should every device be forced to use macros and pay the cost of
> byte-swap code if the MMU/DMA setup/whatever can be can be configured to
> do away with any explicit byte swapping?  Especially if there are no byte
> swap instructions so byte swapping is an expensive multi-cycle process?

It shouldn't -- assuming the hardware implementation is reasonable
expressible and standardized.


> The problem with your implementation, especially your hardware
> implementation, is that while you get rid of the byteswaps for structured
> data types, you require byteswaps for stream data, so if you want to write
> a page of data to disk you need to byte-swap the page first.  Doesn't look
> like a win to me.

"Uh, no."  (you're assuming things that i've not said, and incorrectly
at that.)

Logically, there's a separation between accesses to command blocks,
etc., which may have fields interpreted as multibyte quantities, and
accesses to data streams.  (This is why, for instance, there are (now)
separate bus_space macros for 'normal' and 'stream.'.)

Hardware can -- and in some cases does -- provide both ways about it.



cgd