>With the recent commit of preliminary support for the Avalon Computer Systems
>A12 Scalable Parallel Processor to NetBSD/alpha, I have been rethinking
>the semantics of bus_dmamap_sync().

>In particular, I am no longer very happy with the BUS_DMAMEM_NOSYNC option
>to bus_dmamem_map(), which allows DMA-safe memory to be mapped in such a
>way that bus_dmamap_sync() calls are not required.  I agree with Ross Harvey's
>assessment of this option: it's really the only hole in the bus_dma

Yes, It's a hole but a damned useful one.  I have a device which can
happily mmap dozens of megabytes of network DMA buffers directly into
userspace; it's really nice to make later sych ops a no-op if the
hardware supports it.  I can see the same thing being equally useful
for Matt's FDDI drivers, too.

How about this as a compromise: 
	a) we leave DMAMEM_NOSYNC as an option, but change the semantics,
	   so it's a hint which bus-dma implementations may legitimately
	   ignore;

	b) bus-dma clients are _required_ to  do the appropriate
	   synchronization ops even if they asked for  a DMAMEM_NOSYNC
	   mapping;

	c) bus-dma implementations that _can_ give DMAMEM_NOSYNC 
	   semantics may encode the request for DMAMEM_NOSYNC  in
	   their bus tags; regions successfully mapped as NOSYNC may
	   treat later synch ops on the NOSYNC region as no-ops.

I'd much much rather have that option, than to kill NOSYNC altogether,
specially on those very splendid and worthwhile boxes where DMA is
non-cache-coherent...

Comments?