On Tue, 6 Mar 2001, Ross Harvey wrote:

> >:::
> >                                                          ... The assumption
> >  > that a post-mapping 'sync' operation exists is a flawed assumption.
> 
>   -- either everything needs to be coherent or sync needs to work, obviously
>   one or the other must work. Both need to be in the interface.  It's really
>   hard to find fault with *that* assumption. If you still think there is a
>   problem here please specify it more precisely.

I think I meant to that the assumption that a "sync" can always work can only
be true if the knowledge that you'll need to sync without unmapping is known
when you do the mapping for the device (not necessarily the mapping for the
CPU), in which case the sync is 'no-op' on this platform.

> 
> >:::
> >  > 2. But real memory is allocated (in the order above) prior to the call to
> >  > bus_dmamem_map.
> 
> Well, actually, it doesn't have to be allocated here, it just has to be
> _specified_ there because that's the bus_dma(9) interface. And obviously,
> it has to ultimately be coherent or sync-capable, so what's the problem?

>...
> 
> For that matter, if the platform is totally wacky it can just make a thunk
> and postpone the allocation, or it can later free it and reallocate things
> if it gets a more difficult and unusual coherent case. The sync calls are
> still needed for the proper interface, even if they need not do anything
> for a specific mapping.
> 
> I've seen more unusual things than sparc64 fit into the bus_dma(9) framework
> as it stands right now, and I bet sparc64 could too if properly implemented.

I don't believe that sparc64 and an IOMMU that has streaming or byte-coherent
mode is all that 'wacky'. The same issues occur in sparc- but there is an
*implicit* allocation of byte coherent memory (for both the device and the
CPU) in NetBSD/sparc.

In theory you *could* do the alloc/realloc if you really wanted to get
aggressive with opaque handles. That's also a fine implementation strategy.
However, Eduardo and I have been raising what we consider a narrowness of
scope of the current architecture too. It seems to us that it'd be better to
give a hint earlier. Clearly some people think that this spec is perfect and
shouldn't change. Saying that the sparc64 is wacky or just buggy is not either
correct or accurate when we're raising legitimate questions about the
architecture.

As I've also said- it's fine too if the spec doesn't change- I've convinced
myself that it's still possible to build a workable platform with the current
bus_dma architecture (after I've read some of what's been clarified). But the
man page which *is* the definitive architectural reference (no, not existing
implementation) should be expanded upon (with the conclusions of all of this
mail) to at least state the required order of usage, the intent of
bus_dmamap_load_raw (which in the man page is just plain *wrong* compared to
what Jason said), clarify that it is not possible to have enough of a hint to
create peer-peer DMA areas that are byte-coherent (for platforms that cannot
'sync').

-matt