Hello. Benjamin Herrenschmidt wrote:
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.
Bart has just named one reason for that -- many chips have shared PIO/DMA timing regs -- not all driver actually care about that issue and that's *not* the safest way to do this via ide_dma_{on|off}() calls anyway...
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.
Hm... "it's the way the cookie crumbles" for all the other drivers. :-)
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.
No. DMA is still diabled for the IDE core at this point. You need a real ide_dma_on() method call to do it.
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
