On Friday 29 May 2009 22:07:12 Sergei Shtylyov wrote: > pdc202xx_reset() calls pdc202xx_reset_host() twice, for both channels, while > that function actually twiddles the single, shared software reset bit -- the > net effect is a duplicated reset and horrendous 4 second delay happening not > only on a channel reset but also when dma_lost_irq() and dma_clear() methods > are called. Fold pdc202xx_reset_host() into pdc202xx_reset(), fix printk(), > and move it before the actual reset... > > Signed-off-by: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx> > > --- > The patch is against the ide-2.6.git master branch... > > Bart, I know you have the docs... from the now removed source code I was able > to figure out that the bit in question most probably drives RST- signal on both > channels (it seems to require re-tuning drives on both channels which we are > currently not doing). If I'm right, why the hell we're twiddling it on a normal > SRST reset, and what's worse on an interrupt timeout conditions? Anyway, it's Unfortunately the documentation doesn't say anything more than that the changing of the bit value results in SRST on both channels... IIRC from some old discussions this is required by the chipset sometimes.. > hardly a good idea to reset both channels when you only have problem with only > one of them, and I don't see any justification to doing that... So maybe this > patch should've actually wiped out that whole reset insanity for good?.. I'm pretty sure that there are valid reasons behind some of this insanity, OTOH (per mail from Alan) it completely ignores the fact that the other port may be active.. We may try removing it in incremental patch so it is easier to track/revert it if things go wrong.. -- 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
