On Sat, Nov 19, 2011 at 08:38:42PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 10-08-2006 21:52, Alan Cox wrote:
>
> >>From nobody Mon Sep 17 00:00:00 2001
> >From: root<root@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> >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...
Oh, that's a long time ago indeed. I got these from the ATA spec, a
rather ancient one, too, plus the programming interface datasheets for
the AMD, VIA, Intel and SiS chipsets.
I don't remember why the setup timing is specified with MWDMA, my
assumption, though, is that this is because the timing registers were
programmed once for a drive and then kept regardless what kind of
command was sent there.
And there was a chance that commands resulting in PIO transfers
(identify, perhaps?) would be issued, and for these the setup register
needed to be programmed to a sensible value.
Or, possibly, these old chipsets used the same setup register for the
DIOR-/DIOW- timing in MWDMA mode.
I'm afraid that with the scarce documentation back then, the ultimate
decision was made on what worked and what resulted in timeouts.
> 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?
Vojtech
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
