> Right, this is why I specified in the API definition that memory allocated
> with bus_dmamem_alloc() is guaranteed to map into DMA space according
> to the constraints specified.  In the case of the Avalon A12, it can be
> any page in memory, because DMA on that system is always bounced via a
> special SRAM buffer.  On the SPARC, it can be any page, because you can
> remap it with the IOMMU/DVMA facilities.  On the PC and on some Alphas,
> the memory allocated actually has to match those constraints.
> 
> What I'm saying is that the interface was very carefully defined to allow
> for this kind of opaque behavior underneath.
> 
> I don't see any reason why the current API definition can't be correctly
> implemented on the SPARC.

Sure, using this definition there is no problem with implementation with
respect to the DMA capabilities provided by the architecture.

But it doesn't cater for devices which actually need alignment
constraints for themselves. For instance, a network driver might be
able to use DMA at arbitrary addresses when accessing packet buffers
but needs its ring descriptor to be aligned (HME is an example of this,
though it won't pose a problem in practice because it needs a 2KB
alignment which is smaller than all(?) archs' page size).

-pk