Stupid question about DMA on strange hardware

Hi,

 please cc me on any replies, I'm not subscribed here.

Those with an intolerance of broken hardware should look away now.  I'm
trying to use an AmigaOne / MAI Teron mobo from Eyetech, this has a
number of "issues".  The one I'm concerned with here is cache coherency.
This board uses the 'Articia S' chipset which apparently has a floating
DMA buffer. ( I don't have any documentation, and neither MAI nor
Eyetech respond to my mail.)  When Bill Mueller was at MAI he produced
the following hack (edited) with a similar hack for ide_dma_write


int __ide_dma_read (ide_drive_t *drive /*, struct request *rq */)
{
 [snip]
	unsigned int count	= 0;
 [snip]
	if (!(count = ide_build_dmatable(drive, rq, PCI_DMA_FROMDEVICE)))
		/* try PIO instead of DMA */
		return 1;
#ifdef CONFIG_AMIGAONE   /* MAI: make sure RAM's copy of dma table is up to date */
	flush_dcache_range (hwif->dmatable_cpu, hwif->dmatable_cpu + (count << 3));
#endif


 Clearly this isn't suitable for mainline, but my first priority is to
get 2.6 kernels running reliably before I ask for the code to be
reviewed.  I got 2.6.9 running [1] and thought at first that an add-on
sii controller had solved the problem, but I've now accepted the
problems are still there.  Copy a tree to another partition using tar |
tar and maybe 1 or 2 files out of 10000 are corrupt.  Use scp to copy
_big_ files (> 512MB) and sometimes the md5sum is wrong, but rerunning
md5sum will then produce the correct result.

 Looking at Bill's hack, the length of the cache being flushed is always
(0 << 3) bytes, because ide_build_dmatable returns 0 or 1 ?  Or have I
added 2 + 2 and got 5, again ?  Can anyone give me some pointers to
determine the length of the buffers used in __ide_dma_read and
__ide_dma_write, please ?

TIA,

Ken

1. patches at http://homepage.ntlworld.com/zarniwhoop/kernel/kernel.html
-- 
 das eine Mal als Tragödie, das andere Mal als Farce