On Sat, 24 Feb 2001, Izumi Tsutsui wrote:

> In <Pine.BSF.4.21.0102231737080.38524-100000@beppo.feral.com>
> mjacob@feral.com wrote:
> 
> > Izumi is not correct about bus_dmamap_sync missing.
> 
> Hmm, Ok, I take a look at isp_sbus.c.
> 
> It seems there is no bus_dmamap_sync() with BUS_DMASYNC_PREREAD
> for sbus_result_dmamap. I don't check bus_dmamap_sync()
> implementation of sparc64, but this might cause problem.

You don't need a preread because the CPU never writes the response queue- only
the device. The man page says:

              Synchronization operations are expressed from the perspective of
              the host RAM, e.g. a device -> memory operation is a READ and a
              memory -> device operation is a WRITE.

Ergo, after the ISP writes the response queue a BUS_DMASYNC_POSTREAD sync
is done to synchronize the CPU's view of the response queue.

The current imp


> bus_dmamap_sync() with BUS_DMASYNC_POSTWRITE for sbus_rquest_dmamap
> seems also missed, but this would not cause any problem since
> POSTWRITE sync is mostly no-op.


The last checkin uncommented the #if 0 around such a BUS_DMASYNC_POSTWRITE.

Whether it 'causes a problem' is irrelevant for proper multiplatform
design.

The problem here now is that bus_dmamem_map with BUS_DMA_COHERENT
is not sufficient on sun4u- the addition to BUS_DMA_COHERENT made
something work. I'll have to find out why this is the case for
sun4u.

> 
> BTW, isp_sbus.c has some bus_dmamap_sync calls like:
> 
> 	bus_dmamap_sync(sbc->sbus_dmatag, dmap, dmap->dm_segs[0].ds_addr,
> 	    xs->datalen, in? BUS_DMASYNC_PREREAD : BUS_DMASYNC_PREWRITE);
> 
> It looks completely wrong to specify dm_segs[].ds_addr for offset.


Good spotting. Thank you.

-matt
>