Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 10月, 2007 3 次提交
    • B
      ide: move ide_rate_filter() calls to the upper layer (take 2) · f212ff28
      由 Bartlomiej Zolnierkiewicz 提交于 
      * Move ide_rate_filter() calls from host drivers to IDE core.

* Make ide_rate_filter() static.

* Make 'speed' argument of ->speedproc const.

v2:
* Fix it8213_tune_chipset() comment.

There should be no functionality changes caused by this patch.
Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      f212ff28
    • B
      ide: mode limiting fixes for user requested speed changes · 7670df73
      由 Bartlomiej Zolnierkiewicz 提交于 
      * Add an extra argument to ide_max_dma_mode() for passing requested transfer
  mode.  Use it as an upper limit when finding the best DMA for device/host.

* Rename ide_max_dma_mode() to ide_find_dma_mode() and at the same time add
  ide_max_dma_mode() wrapper which passes XFER_UDMA_6 as a requested mode to
  ide_find_dma_mode().  Also add inline ide_find_dma_mode() version for
  CONFIG_BLK_DEV_IDEDMA=n case.

* Pass requested transfer mode from ide_find_dma_mode() to ide_get_mode_mask()
  to avoid false warning from eighty_ninty_three().

* Use ide_find_dma_mode() to limit the user requested transfer mode in
  ide_rate_filter().  Also limit the requested mode by host max PIO mode.


Above changes make ide_rate_filter() to:

* Clip desired transfer mode down if it is invalid (values 0x0F, 0x13-0x19
  and 0x25-0x39, values > 0x46 were already clipped down, same for values
  0x25-0x39 but iff UDMA was not supported by the host).

* Clip desired transfer mode down if it is currently unsupported by IDE core
  (PIO6 and MWDMA3-4, the latter were already clipped down but iff UDMA was
  not supported by the host).

* Clip desired transfer mode down according to the host capabilities
  (UDMA modes were already clipped down but MWDMA/SWDMA/PIO weren't,
  also ->atapi_dma flag was not respected).

* Clip desired transfer mode down according to the device capabilities
  (except PIO modes for now which require mode work) - shouldn't be a
  problem since ide_set_xfer_rate() is called _after_ device has accepted
  given transfer mode.

and also result in a number of host driver specific bugfixes:

* icside
  - clip unsupported PIO5 mode down
  - fix unsupported/invalid modes being set in drive->current_speed

* ide-cris
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - clip DMA modes down for ATAPI devices
  - fix BUG() on unsupported/invalid modes

* au1xxx-ide
  - clip unsupported PIO5, SWDMA0-2 and MWDMA0-2
    (if BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=n) modes down

* aec62xx
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - clip DMA modes down for ATAPI devices
  - fix 0x00 being programmed as PIO timing for unsupported/invalid modes
  - fix unsupported/invalid modes being set on the device

* alim15x3
  - clip DMA modes down for ATAPI devices (chipset revision == 0x20 only)
  - fix theoretical OOPS for 0x0F mode
  - fix unsupported/invalid modes being set on the device

* amd74xx
  - clip unsupported SWDMA0-2 (on COBRA_7401 revs <= 7) modes down
  - fix random PIO timings being set for unsupported/invalid modes
  - fix unsupported/invalid modes being set on the device

* atiixp
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix cached MWDMA mode being cleared for unsupported/invalid modes
  - fix PIO{0,2} timings being programmed for unsupported/invalid modes
  - fix theoretical OOPS for PIO5-6 and 0x0F modes
  - fix unsupported/invalid modes being set on the device

* cmd64x
  - clip unsupported SWDMA0-2 modes down

* cs5530
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix unsupported/invalid modes being set on the device
  - fix BUG() on unsupported/invalid modes
    (which happened if the device accepted the setting)

* cs5535
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix unsupported/invalid modes being set on the device
  - fix theoretical OOPS for PIO5-6 and 0x0F modes

* hpt34x
  - clip DMA modes down for ATAPI devices
  - fix invalid timings being programmed for unsupported/invalid modes
  - fix unsupported/invalid modes being set on the device

* hpt366
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix PIO0 timings being programmed for unsupported/invalid modes
  - fix DMA timings being cleared for MWDMA3-4 and 0x25-0x39 modes
  - fix unsupported/invalid modes being set on the device

* it8213
  - clip unsupported PIO5, SWDMA0-1 and MWDMA0 modes down

* it821x
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - clip DMA modes down for ATAPI devices
    (chipset in smart mode and revision 0x10 in pass-through mode)

* jmicron
  - clip unsupported SWDMA0-2 modes down
  - fix unsupported/invalid modes being set on the device

* pdc202xx_new
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix unsupported/invalid modes being set on the device

* pdc202xx_old
  - clip unsupported PIO5 mode down
  - fix incorrect timings being set for unsupported/invalid modes
  - fix unsupported/invalid modes being set on the device

* piix
  - clip unsupported PIO5, SWDMA0-1 and MWDMA0 modes down

* sc1200
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix unsupported/invalid modes being set on the device
  - fix BUG() on unsupported/invalid modes
    (which happened if the device accepted the setting)

* scc_pata
  - clip unsupported PIO5, SWDMA0-2 and MWDMA0-2 modes down

* serverworks
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix DMA/UDMA timings/settings being cleared for unsupported/invalid modes
  - fix unsupported/invalid modes being set on the device

* siimage
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - clip DMA modes down for ATAPI devices (SATA chipsets)

* sis5513
  - clip unsupported PIO5 mode down
  - fix BUG() on unsupported/invalid modes

* sl82c105
  - clip unsupported SWDMA0-2 modes down

* slc90e66
  - clip unsupported PIO5, SWDMA0-1 and MWDMA0 modes down

* tc86c001
  - clip unsupported PIO5 and SWDMA0-2 modes down
  - fix PIO0 timings being programmed for PIO5/0x0F/SWDMA0-2/0x13-0x19 modes
  - fix invalid 0x00 DMA timing being programmed for MWDMA3-4/0x25-0x39 modes
  - fix unsupported/invalid modes being set on the device

* triflex
  - clip unsupported PIO5 mode down

* via82cxxx
  - fix random PIO timings being set for unsupported/invalid modes
  - fix unsupported/invalid modes being set on the device

* pmac
  - clip unsupported PIO5 and SWDMA0-2 modes down

* cmd640/ht6560b
  - clip DMA modes down (if CONFIG_BLK_DEV_IDEDMA=y)
  - fix PIO5 being clipped to PIO4 (if CONFIG_BLK_DEV_IDEDMA=n)

* opti621
  - clip DMA modes down (if CONFIG_BLK_DEV_IDEDMA=y)
  - clip unsupported PIO4 to PIO3 (if CONFIG_BLK_DEV_IDEDMA=n)


While at it:

* Use ide_rate_filter() in cs5520.c::cs5520_tune_chipset().

* Remove no longer needed checks from hpt366.c::hpt3{6,7}x_tune_chipset().
Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      7670df73
    • S
      hpt366: MWDMA filter for SATA cards (take 2) · b4e44369
      由 Sergei Shtylyov 提交于 
      The Marvell bridge chips used on HighPoint SATA cards do not seem to support
the MWDMA modes (at least that could be seen in their so-called drivers :-),
so the driver needs to account for this -- to achieve this:

- add mdma_filter() method from the original patch by Bartlomiej Zolnierkiewicz
  with his consent;

- install the method for all chips to only return empty mask if a SATA drive
  is detected on HPT372{AN]/374 chips...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      b4e44369
  3. 12 9月, 2007 2 次提交
    • S
      hpt366: UltraDMA filter for SATA cards (take 2) · 2808b0a9
      由 Sergei Shtylyov 提交于 
      The Marvell bridge chips used on HighPoint SATA cards do not seem to support
the UltraDMA modes 1, 2, and 3 as well as any MWDMA modes, so the driver needs
to account for this in the udma_filter() method.  In order to achieve that, do
the following changes:

- install the method for all chips, not only HPT36x/370 and improve the code
  formatting by killing the extra tabs while at it;

- add to the end of the 'switch' statement in the method cases for HPT372[AN]
  and HPT374 chips upon which the known SATA cards are based;

- use hwif->ultra_mask as a default mask for the ide_dma_filter() method to
  behave correctly;

- move the HPT370[A] cases below the HPT36x case for consistency.

While at it, replace the explicit UltraDMA mode masks with ATA_UDMA* constants
all over the driver...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bob Ham <rah@bash.sh>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      2808b0a9
    • S
      hpt366: fix PCI clock detection for HPT374 (take 4) · 72931368
      由 Sergei Shtylyov 提交于 
      HPT374 BIOS seems to only save f_CNT register value for the function #0 before
re-tuning DPLL (that causes the driver to report obviously distorted f_CNT for
the function #1) -- fix this by always reading the saved f_CNT register value
from the function #0 in the driver's init_chipset() method.
While at it, introduce 'chip_type' for holding the 'struct hpt_info' field
of the same name and replace the structure assignment with memcpy()...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      72931368
  5. 20 7月, 2007 4 次提交
  7. 12 7月, 2007 1 次提交
    • A
      PCI: Change all drivers to use pci_device->revision · 44c10138
      由 Auke Kok 提交于 
      Instead of all drivers reading pci config space to get the revision
ID, they can now use the pci_device->revision member.

This exposes some issues where drivers where reading a word or a dword
for the revision number, and adding useless error-handling around the
read. Some drivers even just read it for no purpose of all.

In devices where the revision ID is being copied over and used in what
appears to be the equivalent of hotpath, I have left the copy code
and the cached copy as not to influence the driver's performance.

Compile tested with make all{yes,mod}config on x86_64 and i386.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      44c10138
  9. 10 7月, 2007 4 次提交
    • B
      ide: add short cables support · 49521f97
      由 Bartlomiej Zolnierkiewicz 提交于 
      This patch allows users to override both host and device side cable detection
with "ideX=ata66" kernel parameter.  Thanks to this it should be now possible
to use UDMA > 2 modes on systems (laptops mainly) which use short 40-pin cable
instead of 80-pin one.

Next patches add automatic detection of some systems using short cables.

Changes:

* Rename hwif->udma_four to hwif->cbl and make it u8.

* Convert all existing users accordingly (use ATA_CBL_* defines while at it).  

* Add ATA_CBL_PATA40_SHORT support to ide-iops.c:eighty_ninty_three().

* Use ATA_CBL_PATA40_SHORT for "ideX=ata66" kernel parameter.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      49521f97
    • S
      hpt366: simplify UltraDMA filtering (take 4) · 2648e5d9
      由 Sergei Shtylyov 提交于 
      Simplify UltraDMA mode filtering in the driver:

- make use of the newly introduced 'udma_mask' field of 'ide_pci_device_t' to
  set the correct hwif->ultra_mask, modifying init_setup_hpt366() to select
  the correct mask based on the chip revision;

- replace 'max_mode' field of the 'struct hpt_info' with 'max_ultra' specifying
  the maximum UltraDMA mode allowed;

- rewrite hpt3xx_udma_filter() to differ the filters based on the 'chip_type'
  field, and only use it for HPT366 and HPT370[A] where it's really necessary.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      2648e5d9
    • S
      ide: make void and rename ide_dma_timeout() method · c283f5db
      由 Sergei Shtylyov 提交于 
      Since ide_dma_timeout() method's result is discarded, make it return 'void'.
While at it, drop 'ide_' from the method's name, drop the '__' prefix from
the default method's name, and do some cleanups in this method driver-wise:

- in ide-dma.c, au1xxx-ide.c, and pdc202xx_old.c, define/use 'hwif' variable;

- in au1xxx-ide.c, get rid of commented out printk();

- in sl82c105.c, get rid of unnecessary variables.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      c283f5db
    • S
      ide: make void and rename ide_dma_lostirq() method · 841d2a9b
      由 Sergei Shtylyov 提交于 
      Since ide_dma_lostirq() method's result is discarded, make it return 'void'.
While at it, rename the method to dma_lost_irq(), drop the '__' prefix from the
default method's name, and do some cleanups in this method driver-wise:

- in aec62xx.c, rename the method in accordance with other drivers, and get rid
  of unnecessary variables there;

- in pdc202xx_old.c, define/use 'hwif' variable;

- in sgiioc4.c, rearrange the code to call the resetproc() method directly.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      841d2a9b
  11. 04 7月, 2007 2 次提交
  13. 08 6月, 2007 1 次提交
  15. 10 5月, 2007 2 次提交
    • B
      ide: add ide_tune_dma() helper · 29e744d0
      由 Bartlomiej Zolnierkiewicz 提交于 
      After reworking the code responsible for selecting the best DMA
transfer mode it is now possible to add generic ide_tune_dma() helper.

Convert some IDE PCI host drivers to use it (the ones left need more work).
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      29e744d0
    • B
      ide: rework the code for selecting the best DMA transfer mode (v3) · 2d5eaa6d
      由 Bartlomiej Zolnierkiewicz 提交于 
      Depends on the "ide: fix UDMA/MWDMA/SWDMA masks" patch.

* add ide_hwif_t.udma_filter hook for filtering UDMA mask
  (use it in alim15x3, hpt366, siimage and serverworks drivers)
* add ide_max_dma_mode() for finding best DMA mode for the device
  (loosely based on some older libata-core.c code)
* convert ide_dma_speed() users to use ide_max_dma_mode()
* make ide_rate_filter() take "ide_drive_t *drive" as an argument instead
  of "u8 mode" and teach it to how to use UDMA mask to do filtering
* use ide_rate_filter() in hpt366 driver
* remove no longer needed ide_dma_speed() and *_ratemask()
* unexport eighty_ninty_three()

v2:
* rename ->filter_udma_mask to ->udma_filter
  [ Suggested by Sergei Shtylyov <sshtylyov@ru.mvista.com>. ]

v3:
* updated for scc_pata driver (fixes XFER_UDMA_6 filtering for user-space
  originated transfer mode change requests when 100MHz clock is used)
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      2d5eaa6d
  17. 06 5月, 2007 1 次提交
  19. 21 4月, 2007 1 次提交
  21. 17 2月, 2007 5 次提交
  23. 08 2月, 2007 9 次提交
    • S
      hpt366: HPT36x PCI clock detection fix · 6273d26a
      由 Sergei Shtylyov 提交于 
      Fix minor coding mistake in the HPT36x PCI clock detection code noticed by
Bartlomiej Zolnierkiewicz -- it always reported 33 MHz due to the missing
'break' statements.  This, however, most probably never mattered -- in fact, I
was thinking of removing the 25/40 MHz cases completely since HPT36x BIOSes
didn't seem to set any other value than 7 into the 'cmd_high_time' field, i.e.
 supported only 33 MHz PCI.

Note that in the original driver there was another bug: 25 and 40 MHz cases
were interchanged.  Since the 'cmd_high_time' field is in units of PCI clocks,
a lower clock count just *cannot* correspond to a higher frequency, i.  e.  it
should be 5 for 25 MHz PCI and 9 for 40 MHz PCI, not the other way around.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      6273d26a
    • S
      hpt366: init code rewrite · 7b73ee05
      由 Sergei Shtylyov 提交于 
      Finally, rework the driver init.  code to correctly handle all the chip
variants HighPoint has created so far.  This should cure the rest of the
timing issues in the driver (especially, on 66 MHz PCI) caused by the
HighPoint's habit of switching the base DPLL clock with every new revision
of the chips...

  - switch to using the enumeration type to differ between the numerous chip
    variants, matching PCI device/revision ID with the chip type early, at the
    init_setup stage;

  - extend the hpt_info structure to hold the DPLL and PCI clock frequencies,
    stop duplicating it for each channel by storing the pointer in the pci_dev
    structure: first, at the init_setup stage, point it to a static "template"
    with only the chip type and its specific base DPLL frequency, the highest
    supported DMA mode, and the chip settings table pointer filled, then, at
    the init_chipset stage, allocate per-chip instance  and fill it with the
    rest of the necessary information;

  - get rid of the constant thresholds in the HPT37x PCI clock detection code,
    switch  to calculating  PCI clock frequency based on the chip's base DPLL
    frequency;

  - switch to using the DPLL clock and enable UltraATA/133 mode by default on
    anything newer than HPT370/A;

  - fold PCI clock detection and DPLL setup code into init_chipset_hpt366(),
    unify the HPT36x/37x setup code and the speedproc handlers by joining the
    register setting lists into the table indexed by the clock selected;

  - add enablebits for all the chips to avoid touching disabled channels
    (though the HighPoint BIOS seem to only disable the primary one on
    HPT371/N);

  - separate the UltraDMA and MWDMA masks there to avoid changing PIO timings
    when setting an UltraDMA mode in hpt37x_tune_chipset().

This version has been tested on HPT370/302/371N.

Thanks to Alan for the inspiration. Hopefully, his libata driver will also
benefit from the work done on this "obsolete" driver...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      7b73ee05
    • S
      hpt366: clean up DMA timeout handling for HPT370 · 4bf63de2
      由 Sergei Shtylyov 提交于 
      Clean up DMA timeout handling for HPT370:

- hpt370_lostirq_timeout() cleared the DMA status which made __ide_dma_end()
   called afterwards return the incorrect result, and the DMA engine was reset
   both before and after stopping DMA while the HighPoint drivers only do it
   after (which seems logical) -- fix this and also rename the function;

- get rid of the needless mutual recursion in hpt370_ide_dma_end() and
   hpt370_ide_dma_timeout();

- get rid of hpt370_lostirq_timeout() since hwif->ide_dma_end() called from
   the driver's interrupt handler later does all its work.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      4bf63de2
    • S
      hpt366: merge HPT37x speedproc handlers · 26ccb802
      由 Sergei Shtylyov 提交于 
      Continue with the driver rewrite:

- move the interrupt twiddling code from the speedproc handlers into the
    init_hwif_hpt366 which allows to merge the two HPT37x speedproc handlers
    into one;

- get rid of in init_hpt366 which solely consists of the duplicate code, then
    fold init_hpt37x() into init_chipset_hpt366();

- fix hpt3xx_tune_drive() to always set the PIO mode requested, not the best
    possible one, change hpt366_config_drive_xfer_rate() accordingly, simplify
    it a bit;

- group all the DMA related code together init_hwif_hpt366(), and generally
    clean up and beautify it.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      26ccb802
    • S
      hpt366: cache channel's MCR address · abc4ad4c
      由 Sergei Shtylyov 提交于 
      Begin the real driver redesign. For the starters:

- cache the offset of the IDE channel's MISC. control registers which are used
   throughout the driver in hwif->select_data;

- only touch the relevant MCR when detecting the cable type on HPT374's
   function 1;

- make HPT36x's speedproc handler look the same way as HPT37x ones; fix the
   PIO timing register mask for HPT37x.

- rename all the HPT3xx register related variables consistently; clean up the
   whitespace.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      abc4ad4c
    • S
      hpt366: switch to using pci_get_slot · b4586715
      由 Sergei Shtylyov 提交于 
      Switch to using pci_get_slot() to get to the function 1 of HPT36x/374 chips --
there's no need for the driver itself to walk the list of the PCI devices, and
it also forgets to check the bus number of the device found.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      b4586715
    • S
      hpt366: print the real chip name at startup · 90778574
      由 Sergei Shtylyov 提交于 
      - Rework the driver setup code so that it prefixes the driver startup
  messages with the real chip name.

- Print the measured f_CNT value and the DPLL setting for non-HPT3xx
  chips as well.

- Claim the extra 240 bytes of I/O space for all chips, not only for
  those having PCI device ID of 0x0004.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      90778574
    • A
      hpt366: rework rate filtering tidy · f36702b4
      由 Andrew Morton 提交于 
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      f36702b4
    • S
      hpt366: rework rate filtering · e139b0b0
      由 Sergei Shtylyov 提交于 
      - Rework hpt3xx_ratemask() and hpt3xx_ratefilter() so that the former
  returns the max.  mode computed at the load time and doesn't have to do
  bad Ultra33 drive list lookups anymore; remove the duplicate code from
  the latter function.  Move the quirky drive list lookup into
  hpt3xx_quirkproc() where it should have been from the start...

- Disable UltraATA/100 for HPT370 by default as the 33 MHz ATA clock
  being used does not allow for it, and this *greatly* increases the
  transfer speed.

- Save some space by using byte-wide fields in struct hpt_info; switch to
  reading the 8-bit PCI revision ID reg.  only, not the whole 32-bit reg.

- Start incrementing the driver version number with each patch (should
  have been done from the first one posted).
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      e139b0b0
  25. 27 1月, 2007 1 次提交
  27. 14 12月, 2006 4 次提交