On Monday 05 March 2007, Sergei Shtylyov wrote: > Hello, I wrote: > > >> official == same as in the docs and vendor driver :-) > > >>> Erm, those look a bit doubtful... > > >> I believe that they are correct - please see explanations below. > > > Yeah, sorry about that. Only SWDMA timings are suspicious. > > Hm, too early to say sorry. I was hasty/distacted and forgot what I was > going to write... :-) > > >>>> Index: b/drivers/ide/pci/pdc202xx_old.c > >>>> =================================================================== > >>>> --- a/drivers/ide/pci/pdc202xx_old.c > >>>> +++ b/drivers/ide/pci/pdc202xx_old.c > >>> > >>> [...] > > >>>> @@ -161,7 +95,7 @@ static int pdc202xx_tune_chipset (ide_dr > >>>> case XFER_UDMA_0: > >>>> case XFER_MW_DMA_2: TB = 0x60; TC = 0x03; break; > >>>> case XFER_MW_DMA_1: TB = 0x60; TC = 0x04; break; > >>>> - case XFER_MW_DMA_0: > >>>> + case XFER_MW_DMA_0: TB = 0xE0; TC = 0x0F; break; > > >>> This seems even slower than SWDMA0! > >>> Let's assume that means 7 active cycles and 15 recovery cycles > >>> (MWDMA1/2 settings seem to confirm this hypothesis) -- this would > >>> give us 720 ns vs the specified 480. Could you shed some light on > >>> what these fields mean? :-/ > > >> The calculations are done in a different way so we get the correct > >> timings: > > >> 7 cycles (== 210 ns) are used for active time > > Ugh, forgot to say: this is overclocked, 215 ns is the minimum active time > for this mode. I know that is why I wrote in my previous mail: "These timings are the maximum possible ones using MB[2:0] and MC[3:0]" Driver can't do better than hardware and hopefully these 5 ns are compensated somehow by the chipset (or not :-). Bart - 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
