Subject: Re: bus_dmamem accessors
To: Eduardo Horvath <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 07/31/2000 12:42:47
Eduardo Horvath <email@example.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
(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
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.