aboutsummaryrefslogtreecommitdiff
path: root/drivers/hwmon
diff options
context:
space:
mode:
authorBartlomiej Zolnierkiewicz <bzolnier@gmail.com>2007-05-16 00:51:42 +0200
committerBartlomiej Zolnierkiewicz <bzolnier@gmail.com>2007-05-16 00:51:42 +0200
commit9445de76c124e90176b5116cf82f6cd1413f5230 (patch)
treef48fa3b9f1291a804a3ac434d6140c8a0e4a4969 /drivers/hwmon
parent4fce3164b84d5b014acbf5a3f57eb3650e154f5b (diff)
serverworks: PIO mode setup fixes
* limit max PIO mode to PIO4, this driver doesn't support PIO5 and attempt to program PIO5 by svwks_tune_chipset() could result in incorrect PIO timings being programmed and possibly the data corruption (it seems that the minimum possible values were used but I lack the datasheets to be sure) * select best PIO mode in svwks_tune_drive() and not in svwks_tune_chipset() when doing PIO autotuning (pio == 255) * don't try to tune PIO in config_chipset_for_dma() as ide_dma_enable() could return 1 if DMA was previously enabled (svwks_config_drive_xfer_rate() takes care of PIO tuning if no suitable DMA mode is found) * remove config_chipset_for_pio() and use svwks_tune_drive() instead, config_chipset_for_pio() contained numerous bugs when selecting PIO mode (luckily it was only used for devices limited to PIO by capabilities/BIOS): - it didn't check for validity of id->eide_pio_modes and id->eide_pio_iordy before using them - it tried to found out maximum PIO mode basing on minimum IORDY cycle time (moreover wrong cycle times were used for PIO0/1/5) - it was overriding PIO blacklist and conservative PIO "downgrade" done by ide_get_best_pio_mode() - if the max drive PIO was PIO5 then XFER_PIO_0/XFER_PIO_SLOW was selected (XFER_PIO_SLOW is not supported by svwks_tune_chipset() so the result was the same as if using XFER_PIO_5 => wrong PIO timings were set) - it was overriding drive->current_speed * bump driver version Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Diffstat (limited to 'drivers/hwmon')
0 files changed, 0 insertions, 0 deletions