At 6:46 PM -0500 3/24/05, Tim Kelly wrote:
>Even dbdma.c has problems -
>dbdma_start() overwrites the interrupt conditional in the command building
>and makes generating an interrupt an ALWAYS/NEVER proposition, instead of
>IF_TRUE/IF_FALSE conditional based on parameters such as channel or chip
>errors.

That should read "interrupt select register" instead of "interrupt
conditional." The mask and value combination that is copied into the
interrupt select  in dbdma.c -> dbdma_start() leaves unpredictable results
when a conditional is applied, in addition to having overwritten the mask
and value that was stored there originally.

The comment in the code

dmap->d_intselect = 0xff;  /* Endian magic - clear out interrupts */

is actually incorrect. Interrupt select is a 32 bit register with a 8 bit
mask and a 8 bit value field. The above code in reality attempts to mask
0xff with 0x00, and apparently conditionals are ignored when there is no
mask (I suspect the entire command is skipped). Correct usage of the
interrupt, branch and wait select registers would specify which bits in s7
through s0 to mask and what the value (0 or 1) it should be. Instead of a
blanket ALWAYS on the interrupt select, I use branch select IF_TRUE and
mask s5 = 1 (0x20). Prior to the latest round of discoveries I masked 0xff
with 0xff which picked up any changes in status bits and branched to a set
of commands that shut the channel down and then generated an interrupt. I
haven't worked out the full command structure with the POLL register, which
is specifically implemented by AMD for non-interrupt driven implementations
- i.e., DBDMA.

The big hurdle was re-interpreting "babble" and then being able to
correlate status bits to POLL register bits.

There are several versions of mace driver code for Old World Macs and
mailing list threadds that claim there are problems using mace with curio
and dbdma, because mace was DMA and this doesn't go well with DBDMA. I
simply have not found this to be true. Almost everything I have found that
goes wrong with mc* is related to not properly following the documentation
from Apple. Anybody that has used MacOS and gotten sustained 950KB/sec or
better performance knows that the chipset is perfectly fine (I'm one of
hundreds of thousands who have; MacOS users being the tad demanding people
they are wouldn't have accepted less).

Also, I left out that I use DBDMA commands to read the Tx frame status
register (and a couple others), so that the chip continues to send without
the CPU having to do the work. Except for if there is a need for hardware
flow control or there has been an error, there is no need for interrupts
with DBDMA, and it ought to be possible to handle hardware flow control in
DBDMA as well. It just doesn't seem to work as documented, but I've found
that the documentation requires a lot of reading between the lines (as in,
the docs will say an ethernet implementation of DBDMA is not discussed here
and then that's exactly what is discussed). I suspect I'm missing something.

I'm saying more than I should; I haven't gotten code in a clean enough form
to post, so until then I don't recommend making any changes. I have a few
people that are willing to test as soon as I can finish this, and once they
say it works I'll clean up the code and post it.

tim