DMA IDE problem on the SX164

[Andreas Johansson <ajo wopr campus luth se>]

Hi!

I have earlier explained my intentions to write a IDE DMA driver for the
Cypress chipset in the SX164. Now, my time is extremely limited, so this
is not happening as fast as I would like it to. If anyone has some time
over and is interrested in helping me with the driver, write me a line.

Anyway, the IDE driver is working quite fine and the fastest IDE disk I
have measured tops out at about 7.5MB/s using 13% cpu which seems quite
alright for standard eide to me.

The reason I haven't released the driver is that I have a serious problem.
When I use the DMA driver it hogs the PCI bus during the DMA transfer.
Normally, all PCI devices of this kind has a limitation for how long each
transfer can be, called latency. For example, my NCR 875 SCSI card has a
latency of 32. Unfortunately, the Cypress chipset reports that it doesn't
want a latency at all, implicating that unlimited PCI transfers may be
done. This is probably very good for getting maximum speed on the
interface, but other devices which wants to use the PCI bus simply has to
wait. In my case, the soundcard doesn't have enough buffer to accept this
delay, and the music is affected. If I transfer data with dd using 64k
blocksize the music really sounds bad.

Another thing the happends is that while playing (distorted) music through
my soundcard and transferring data from the IDE drive using the DMA
driver, the transfer speed slows down to about half. This doesn't occur
with SCSI either. I haven't figured out the reason for this yet. Anyone?

At first I tried to set the PCI parameter for latency in the Cypress
device to a more resonable value, but this unfortunately had no effect
what so ever. It seems that the Cypress device is hardwired to inifinite
latency. Great!   I looked this up in the PCI specifications, and it
actually accepts hardwired latencys.

Ok, when this failed I seemed to remeber that there was another way to
limit the maximum transfer using the PCI controller. This proved to be
correct, I can set the hard latency limit using the PYXIS_MAX_LAT
variable. I tried to set this to 64 and this made the problem be less
evident, but still not ok. I think it would go away if I simply lower the
value enough. But unfortunately this had a serious side effect. The X
server locks up with incredible frequency. The machine totally stops and a
hard reset is required. I have a Matrox Millennium.

Now I can't think of any other way to fix this problem except rebuilding
the transfers to be small enough. This will lead to less efficient
transfers, more interrupts and more cpu usage. Is there any other way I
can solve the problem?

/Andreas