diff options
author | Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> | 2007-05-16 00:51:42 +0200 |
---|---|---|
committer | Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> | 2007-05-16 00:51:42 +0200 |
commit | 9445de76c124e90176b5116cf82f6cd1413f5230 (patch) | |
tree | f48fa3b9f1291a804a3ac434d6140c8a0e4a4969 /drivers/hwmon | |
parent | 4fce3164b84d5b014acbf5a3f57eb3650e154f5b (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