Mysterious MWDMA timings (Was: PATCH: Add CFA modes)

[Sergei Shtylyov <sshtylyov@mvista.com>]

Hello.

On 10-08-2006 21:52, Alan Cox wrote:

>> From nobody Mon Sep 17 00:00:00 2001
> From: root<root@hraefn.swansea.linux.org.uk>
> Date: Thu Aug 10 18:06:38 2006 +0100
> Subject: [PATCH] Add compact flash support

> The CFA world has some additional rules and drive modes we need to support for
> newer expansion cards and on embedded boxes

    Sorry, this is very old patch, but the issue I'm going to touch is even 
much older...

> @@ -1913,6 +1945,8 @@ static const struct ata_timing ata_timin
>   	{ XFER_UDMA_4,     0,   0,   0,   0,   0,   0,   0,  30 },
>   	{ XFER_UDMA_3,     0,   0,   0,   0,   0,   0,   0,  45 },
>
> +	{ XFER_MW_DMA_4,  25,   0,   0,   0,  55,  20,  80,   0 },
> +	{ XFER_MW_DMA_3,  25,   0,   0,   0,  65,  25, 100,   0 },

    Alan, I keep wondering where you got these 25 ns setup timings and where 
such numbers for MWDMA modes 0-2 came from (that should rahter be a question 
for Vojtech Pavlik, the author of drivers/ide/ide-timigs.c from which this 
code was apparently copied; I'm including him in the CC in hopes he could 
remember why these numbers occured, though it's about 10 years since that code 
was written) -- they're not in any spec. Actually, according to the comments 
to 'struct ata_timings', its 'setup' field corresponds to address valid to 
DIOR-/DIOW- setup timing (t1) which only makes sense for the PIO modes, so why 
it's not zero for MWDMA modes is beyond me also...
    What I'd like to do is use this field for MWDMA as the CS(1:0) valid to 
DIOR-/DIOW- timing (tM) which seems to correspond to t1 quite closely (and the 
numbers for tM are slightly less than those used on MWDMA modes now) -- the 
controller I'm writing the driver for now has tM timing programmable...
Or should I just a new timing to 'struct ata_timing'? Or should I just keep 
the tM timing table private to the driver as it's the only user of this 
timing? Opinions?

MBR, Sergei