[ moved to tech-kern ]

It also turns out that there's no way in the current sparc64 implementation to
do BUS_DMA_COHERENT without this- I was wrong when I thought I had things
working (I'd missed a BUS_DMA_COHERENT in a load call). The current SBus
Qlogic card driver is now actually broken.

The summary of the issues now is now:

a) bus_dmamem_alloc implies that all memory allocated with this mechanism must
be mapped BUS_DMA_COHERENT. To make sparc64 work requires a 4 line patch to
sys/sparc64/dev/iommu.c.

b) bus_dmamem_alloc (and/or bus_dmamap_load*) should be allowed to take a
BUS_DMA_COHERENT flag such that the memory will be mapped for I/O device
access (on those particular platforms) in fashion that works.


Note that this is completely orthogonal to the requirement of bus_dmamap_sync-
the semantics of bus_dmamap_sync (flushing post mapping but prior to data
movement) may not be possible on some platforms. This is the opposite case to
what has been mentioned before (that bus_dmamap_sync is required because there
may be platforms you *cannot* map BUS_DMA_COHERENT).

Note also that this is and should be orthogonal to bus_dmamem_map. You may
need to map memory that is BUS_DMA_COHERENT for two separate devices- but not
including a CPU with virtual address mapping to the memory involved.



I've spoken to one of the people involved on one side of this issue- and have
concluded from recent email and past interactions with the main person on the
other side that there is an impasse such that neither side seems willing to
change what to accomodate either #a or #b. I've asked core@netbsd.org to
please become involved to reconcile the differences. I'd also like others
within the community to express their opinions about this.


In the interim I plan to take action to make isp_sbus work again for Ultra1.

-matt

p.s.: My own opinion, FWIW, is that choice #b is better. But I don't care all
that much because I certainly could live with choice #a.

What *does* annoy the hell out of me is to be publicly criticised for just
making things work within a framework that already clearly was contradictory.
On the other hand, it made me focus on the architecure side of things for a
while instead of staying down in the 8 zillion linux, solaris, *BSD, and other
different tactical messes I seem to be in. Woo-hoo. *yawn*



> In <Pine.LNX.4.21.0102241905350.25555-100000@zeppo.feral.com>
> mjacob@feral.com wrote:
> 
> > It turns out there are a number of other drivers that are adding
> > BUS_DMA_COHERENT to the bus_dmamap_load* calls as well. Guess they need fixing
> > too.
> 
> Hmm, I guess they are dev/ic/hme.c, dev/sbus/if_le.c and
> dev/sbus/if_le_ledma.c. All of them have no bus_dmamap_sync().
> That's too bad..
> ---
> Izumi Tsutsui
> tsutsui@ceres.dti.ne.jp
>