> > Ok, there's a combination of things here: > > > - First, doing a set_pio from userland (hdparm -p XX) causes the kernel > > to disable DMA, which I think is incorrect. > > That's the way ide_config_drive_speed() works. And I still think that's bad. > > It's not the case with 2.6.22 from my quick tests. > > Which means that PIO autotuning is broken there, i.e. that > ide_config_drive_speed() not called from the driver's tuneproc() method. Yes, the driver uses it's own function which doesn't disable DMA permanently, which is, IMHO, the way to go. I consider the current behaviour a regression. > > The problem is that ide_config_drive_speed > > disables DMA, but only re-enables it when setting a DMA speed. > > It never "re-enables" DMA. ide_dma_host_on() method is not the same as > ide_dma_on() which actually enables DMA. Ugh ? It re-enables DMA in the sense that if called to configure a DMA speed, it re-enables dma on the host, thus effectively leaving with DMA enabled. > > I think > > the whole idea of having a "current speed" is bogus here, we should have > > a separate current DMA speed and current PIO speed. We should be able to > > set the PIO timings without stopping DMA, toggling DMA is a separate > > affair. > > Agreed completely. Ah good :-) Cheers, Ben. - 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
