In article <20010916215257.A219@rxgpc.iplus.net.tw>
rxg@ms25.url.com.tw wrote:

> > 3) All SRBs are allocated by bus_dmamem_alloc(), but
> >    it is better to use bus_dmamem_alloc() only for memory
> >    used to pass parameters to the adapter via DMA,
> >    i.e. only memory for SegmentX[] member should be
> >    allocated by bus_dmamem_alloc(). (see sys/dev/ic/iha*.[ch])
> 
> Can we just split the member from strcut _SRB?

struct _SRB has to have only a pointer to SegmentX array,
which is allocated separately. (see sys/dev/ic/ihavar.h)

> >    Otherwise it causes some performance penalty because
> >    allocated memory by bus_dmamem_alloc() with BUS_DMA_COHERENT
> >    does not use cache on some architectures (like arm and mips).
> 
> It seems to other drivers also do this. :)

Yeah, on i386, DMA-cache coherency is handled by its hardware,
so BUS_DMA_COHERENT and bus_dmamap_sync() is mostly no-op
against cache and there is no penalty on it.
Maybe old drivers were written for only i386,
but now we have many many architectures :-)

> > 4) bus_dmamap_sync with BUS_DMASYNC_PREWRITE is also needed
> >    for SegmentX[] before transfer.
> 
> Please tell me more about this, thanks.

The adapter will fetch values in SegmentX[] address on each transfer,
but the driver should make sure that all values are written-back
into RAM from cache. On i386, cpu automatically does it on each
DMA request, but on many RISC architecture, drivers have to
keep cache coherency explicitly by themselves.

In iha(4) driver, bus_dmamap_sync() called from
iha_exec_scb() and iha_state_5() in sys/dev/ic/iha.c
handle this. See bus_dma(9) man pages for details.

(BTW, cache flush ops by bus_dmamap_sync() is not required
 on architectures which have real BUS_DMA_COHERENT support,
 but BUS_DMA_COHERENT is just a hint and bus_dmamap_sync()
 would also handle transfers for bounce buffers.)
 
> > 6) Maybe some byteswap code is required for big-endian machines.
> >    (But it should be trivial.)
>
> Maybe. :)

Most (but not all) PCI bus-master adapters assume that
its host is lettle endian, so drivers have to read/write
values that are passed via DMA in little endian.

> > 7) It is much better to adapt these sources to KNF :-)
> >    (see /usr/share/misc/style)
> 
> Need more time to do this. X-)

Yes, it is really boring work, but as mentioned in doc/TODO,
"clean code lends itself to further enhancement." :-)

> Thanks for your reply and suggestions!

You're welcome. And good job, again!
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp