Hello.
Alan wrote:
Actually, I think ata_timing_merge() should just be performed when
setting MWDMA mode... This should be the right thing to do in most cases
(however, this hardware has some complications in the form of only 2-bit
wide active/recovery counts and 2 fast timing bank select bits)...
Yeap, that'll be nice. Dunno whether modifying piix/ata_piix too much
would be a good idea tho considering the wide usage.
If I remember rightly the 2bits is ok because you can set the bit to say
that timings are for DMA only,
Yeah, after thinking a bit more, the current logic seems good enough, i.
e. it's better to slow down PIO to mode 0 than further slow down DMA to match
the current PIO speed -- however, this is already happening with MWDMA1 which
is actually faster than PIO3 (150 vs 180 ns). But well, who cares... :-)
the device then uses slower than PIO0 for all other cycles.
Well, thankfully, compatible mode is PIO0 exactly (except for taskfile
accesses which are way slower indeed).
In both mwdma and pio cases, they're just turning off UDMA. Don't know
whether it's actually necessary but still afraid to change it unless
there is a good reason.
The tuning manual I have does it, so I do it 8)
Do you mean 29860004.pdf? Actually, I'm not seeing anything alike here.
It would've been stupid idea to couple UDMA to PIO but well... after looking
at the HighPoint datasheets, one becomes hard to surprise. :-)
Alan
Well, after looking at do_pata_set_dmamode(), I have another question:
why IORDY enable is forced here? It has *nothing* to do with the IDE DMA
protocol. (This also seems to be an issue with piix.c...)
MBR, Sergei
-
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
