Hello.
Bartlomiej Zolnierkiewicz wrote:
* Add { 0, 0 } entry to {kauai,shasta}_pio_timings[] so kauai_lookup_timing()
always returns a valid PIO timing (fixes PIO timing not being set for devices
with minimum PIO cycle <= 120ns).
Ugh... the way those tables are following each other, the driver should be
programming MWDMA2 timings instead. :-/
* Add setting transfer mode on the device to pmac_ide_set_pio_mode().
* Fix pmac_ide_set_pio() to always program chipset for given PIO timing instead
of only when the device we want to program PIO timing for is the currently
selected one.
Hm, why this was necessary?
AFAIU, pmac_ide_do_setfeature() will cause selectproc() to be called
anyway, via SELECT_DRIVE()...
* Now that pmac_ide_set_pio() is fixed there is no need to set transfer mode
on the device and program chipset for PIO in pmac_ide_tune_chipset()
BTW, I'm also not seeing much sense in calling
pmac_ide_do_update_timings() from there as well since pmac_ide_do_setfeature()
is called before that anyway.
(returning 0 == success is not entirely correct but is OK for now since
the upper layers are only checking ->speedproc return value for DMA modes).
This patch should have no effect on the default kernel behavior because
IDE pmac driver doesn't enable ->autotune (this would also explain why some
of the above bugs remained unfixed for so long).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
Acked-by: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx>
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
