All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 26 Apr, 2008 1 commit
  2. 17 Apr, 2008 2 commits
  3. 26 Feb, 2008 1 commit
    • Sam Ravnborg's avatar
      hpt366: fix section mismatch warnings · b66cae76
      Sam Ravnborg authored
      hpt366: fix section mismatch warnings
      
      Fix following warnings:
      WARNING: o-sparc64/vmlinux.o(.data+0x195a38): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370
      WARNING: o-sparc64/vmlinux.o(.data+0x195a40): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt370a
      WARNING: o-sparc64/vmlinux.o(.data+0x195a48): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372
      WARNING: o-sparc64/vmlinux.o(.data+0x195a50): Section mismatch in reference from the variable hpt37x_info.0 to the variable .devinit.data:hpt372n
      
      Replace a static array with a small switch resulting in
      more readable code.
      Mark the pci table __devinitconst.
      
      A lot of variables are const but annotated __devinitdata.
      Annotating them __devinitconst would cause a section type
      conflict error when build for 64 bit powerpc.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      b66cae76
  4. 02 Feb, 2008 2 commits
  5. 01 Feb, 2008 3 commits
  6. 26 Jan, 2008 1 commit
    • Bartlomiej Zolnierkiewicz's avatar
      ide: merge ->fixup and ->quirkproc methods · f01393e4
      Bartlomiej Zolnierkiewicz authored
      * Assign drive->quirk_list in ->quirkproc implementations:
        - hpt366.c::hpt3xx_quirkproc()
        - pdc202xx_new.c::pdcnew_quirkproc()
        - pdc202xx_old.c::pdc202xx_quirkproc()
      
      * Make ->quirkproc void.
      
      * Move calling ->quirkproc from do_identify() to probe_hwif().
      
      * Convert it821x_fixups() to it821x_quirkproc() in it821x.c.
      
      * Convert siimage_fixup() to sil_quirkproc() in siimage.c, also remove
        no longer needed drive->present check from is_dev_seagate_sata().
      
      * Convert ide_undecoded_slave() to accept 'drive' instead of 'hwif'
        as an argument.  Then convert ide_register_hw() to accept 'quirkproc'
        argument instead of 'fixup' one.
      
      * Remove no longer needed ->fixup method.
      Acked-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      f01393e4
  7. 25 Jan, 2008 6 commits
  8. 12 Dec, 2007 1 commit
    • Sergei Shtylyov's avatar
      hpt366: fix HPT37x PIO mode timings (take 2) · 809b53c4
      Sergei Shtylyov authored
      After looking into the HPT370 manual (now that I have it) and re-checking all
      the timing tables, here's what I have discovered:
      
      - at 33 MHz clock, PIO mode 0 timings turned to be overclocked, and all other
        PIO modes underclocked;
      
      - at 50 MHz clock, PIO modes 0 to 2 turned to be overclocked;
      
      - at 66 MHz clock, PIO mode 0 was overclocked too.
      
      Finally, the taskfile timing (matching PIO mode 0) turned to be overclocked at
      all clock frequencies (and in all manuals)...
      
      The new timings have been tested on HPT370 chip (at 33 MHz PCI clock) and on
      HPT371N chip (at both 50 and 66 MHz DPLL clock).
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      809b53c4
  9. 26 Oct, 2007 1 commit
    • Bartlomiej Zolnierkiewicz's avatar
      hpt366: fix build for CONFIG_HOTPLUG=n · 282037f1
      Bartlomiej Zolnierkiewicz authored
      On Saturday 20 October 2007, Avuton Olrich wrote:
      
      > My randconfig script the attached config caught an error on:
      > drivers/ide/pci/cy82c693.c:439: error: primary causes a section type conflict
      >
      > My git tree: c00046c2
      >
      > Bisected to:
      > 85620436 is first bad commit
      > commit 85620436
      > Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      > Date:   Sat Oct 20 00:32:34 2007 +0200
      >
      >     ide: constify struct ide_port_info
      >
      >     Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      
      It turns out that const and __{dev}initdata cannot be mixed currently
      and that hpt366 host driver is also affected by the same issue:
      
      > drivers/ide/pci/hpt366.c:1428: error: hpt366_chipsets causes a section type
      > conflict
      
      This patch workarounds the problem by making static struct hpt_info instances
      const.  Now all __devinitdata data in hpt366 host driver are read-only so it
      builds again (driver's .init.data section gets marked as READONLY).
      
      While at it:
      
      * Bump driver version.
      
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: "Avuton Olrich" <avuton@gmail.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      282037f1
  10. 19 Oct, 2007 2 commits
  11. 18 Oct, 2007 7 commits
  12. 16 Oct, 2007 6 commits
    • Bartlomiej Zolnierkiewicz's avatar
      ide: remove hwif->autodma and drive->autodma · 9ff6f72f
      Bartlomiej Zolnierkiewicz authored
      * hpt34x.c: disable DMA masks for HPT345
        (hwif->autodma is zero so DMA won't be enabled anyway).
      
      * trm290.c: disable IDE_HFLAG_TRUST_BIOS_FOR_DMA flag
        (hwif->autodma is zero so DMA won't be enabled anyway).
      
      * Check noautodma global variable instead of drive->autodma in ide_tune_dma().
      
        This fixes handling of "ide=nodma" kernel parameter for icside, ide-cris,
        au1xxx-ide, pmac, it821x, jmicron, sgiioc4 and siimage host drivers.
      
      * Remove hwif->autodma (it was not checked by IDE core code anyway) and
        drive->autodma (was set by all host drivers - except HPT345/TRM290 special
        cases - unless "ide=nodma" was used).
      
      While at it:
      - remove needless printk() from icside.c
      - remove stale FIXME/comment from ide-probe.c
      - don't force DMA off if PCI bus-mastering had to be enabled in setup-pci.c
        (this setting was always later over-ridden by host drivers anyway)
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      9ff6f72f
    • Bartlomiej Zolnierkiewicz's avatar
      ide: use PCI_VDEVICE() macro · 9cbcc5e3
      Bartlomiej Zolnierkiewicz authored
      While at it:
      - make struct pci_device_id tables const
      - use PCI_DEVICE_ID_ITE_8213 define in it8213.c
      - fix comment in generic.c
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      9cbcc5e3
    • Bartlomiej Zolnierkiewicz's avatar
      ide: remove ->ide_dma_check (take 2) · 0ae2e178
      Bartlomiej Zolnierkiewicz authored
      * Add IDE_HFLAG_TRUST_BIOS_FOR_DMA host flag for host drivers that depend
        on BIOS for programming device/controller for DMA.  Set it in cy82c693,
        generic, ns87415, opti621 and trm290 host drivers.
      
      * Add IDE_HFLAG_VDMA host flag for host drivers using VDMA.  Set it in cs5520
        host driver.
      
      * Teach ide_tune_dma() about IDE_HFLAG_TRUST_BIOS_FOR_DMA flag.
      
      * Add generic ide_dma_check() helper and remove all open coded ->ide_dma_check
        implementations.  Fix all places checking for presence of ->ide_dma_check
        hook to check for ->ide_dma_on instead.
      
      * Remove no longer needed code from config_drive_for_dma().
      
      * Make ide_tune_dma() static.
      
      v2:
      * Fix config_drive_for_dma() return values.
      
      * Fix ide-dma.c build for CONFIG_BLK_DEV_IDEDMA_PCI=n by adding
        dummy config_drive_for_dma() inline.
      
      * Fix IDE_HFLAG_TRUST_BIOS_FOR_DMA handling in ide_dma_check().
      
      * Fix init_hwif_it8213() comment.
      
      There should be no functionality changes caused by this patch.
      
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      0ae2e178
    • Bartlomiej Zolnierkiewicz's avatar
      ide: remove ide_use_fast_pio() · 65c9cd23
      Bartlomiej Zolnierkiewicz authored
      Remove ide_use_fast_pio() and just re-tune PIO unconditionally if DMA tuning
      has failed in ->ide_dma_check.  All host drivers using ide_use_fast_pio() set
      drive->autotune so PIO is always tuned anyway and in some cases we _really_
      need to re-tune PIO because PIO and DMA timings are shared.
      Acked-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      65c9cd23
    • Bartlomiej Zolnierkiewicz's avatar
      ide: remove drive->init_speed zeroing · d3b90baf
      Bartlomiej Zolnierkiewicz authored
      Several host drivers used to reset drive->init_speed in their ->ide_dma_check
      implementations which resulted in incorrect init speed being reported to the
      user, fix it.
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      d3b90baf
    • Bartlomiej Zolnierkiewicz's avatar
  13. 13 Oct, 2007 1 commit
    • Bartlomiej Zolnierkiewicz's avatar
      ide: move ide_config_drive_speed() calls to upper layers (take 2) · 88b2b32b
      Bartlomiej Zolnierkiewicz authored
      * Convert {ide_hwif_t,ide_pci_device_t}->host_flag to be u16.
      
      * Add IDE_HFLAG_POST_SET_MODE host flag to indicate the need to program 
        the host for the transfer mode after programming the device.  Set it
        in au1xxx-ide, amd74xx, cs5530, cs5535, pdc202xx_new, sc1200, pmac
        and via82cxxx host drivers.
      
      * Add IDE_HFLAG_NO_SET_MODE host flag to indicate the need to completely
        skip programming of host/device for the transfer mode ("smart" hosts).
        Set it in it821x host driver and check it in ide_tune_dma().
      
      * Add ide_set_pio_mode()/ide_set_dma_mode() helpers and convert all
        direct ->set_pio_mode/->speedproc users to use these helpers.
      
      * Move ide_config_drive_speed() calls from ->set_pio_mode/->speedproc
        methods to callers.
      
      * Rename ->speedproc method to ->set_dma_mode, make it void and update
        all implementations accordingly.
      
      * Update ide_set_xfer_rate() comments.
      
      * Unexport ide_config_drive_speed().
      
      v2:
      * Fix issues noticed by Sergei:
        - export ide_set_dma_mode() instead of moving ->set_pio_mode abuse wrt
          to setting DMA modes from sc1200_set_pio_mode() to do_special()
        - check IDE_HFLAG_NO_SET_MODE in ide_tune_dma()
        - check for (hwif->set_pio_mode) == NULL in ide_set_pio_mode()
        - check for (hwif->set_dma_mode) == NULL in ide_set_dma_mode()
        - return -1 from ide_set_{pio,dma}_mode() if ->set_{pio,dma}_mode == NULL
        - don't set ->set_{pio,dma}_mode on it821x in "smart" mode
        - fix build problem in pmac.c
        - minor fixes in au1xxx-ide.c/cs5530.c/siimage.c
        - improve patch description
      
      Changes in behavior caused by this patch:
      - HDIO_SET_PIO_MODE ioctl would now return -ENOSYS for attempts to change
        PIO mode if it821x controller is in "smart" mode
      - removal of two debugging printk-s (from cs5530.c and sc1200.c)
      - transfer modes 0x00-0x07 passed from user space may be programmed twice on
        the device (not really an issue since 0x00 is not supported correctly by
        any host driver ATM, 0x01 is not supported at all and 0x02-0x07 are invalid)
      Acked-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      88b2b32b
  14. 11 Oct, 2007 4 commits
    • Bartlomiej Zolnierkiewicz's avatar
      ide: add ide_set{_max}_pio() (take 4) · 26bcb879
      Bartlomiej Zolnierkiewicz authored
      * Add IDE_HFLAG_ABUSE_{PREFETCH,FAST_DEVSEL,DMA_MODES} flags
        and set them in ht6560, cmd640, cmd64x and sc1200 host drivers.
      
      * Add set_pio_mode_abuse() for checking if host driver has a non-standard
        ->tuneproc() implementation and use it in do_special().
      
      * Add ide_set_pio() for setting PIO mode (it uses hwif->pio_mask to find
        the maximum PIO mode supported by the host), also add ide_set_max_pio()
        wrapper for ide_set_pio() to use for auto-tuning.  Convert users of
        ->tuneproc to use ide_set{_max}_pio() where possible.  This leaves only
        do_special(), set_using_pio(), ide_hwif_restore() and ide_set_pio() as
        a direct users of ->tuneproc.
      
      * Remove no longer needed ide_get_best_pio_mode() calls and printk-s
        reporting PIO mode selected from ->tuneproc implementations.
      
      * Rename ->tuneproc hook to ->set_pio_mode and make 'pio' argument const.
      
      * Remove stale comment from ide_config_drive_speed().
      
      v2:
      * Fix "ata_" prefix (Noticed by Jeff).
      
      v3:
      * Minor cleanups/fixups per Sergei's suggestions.
      
      v4:
      * Fix compile problem in drivers/ide/pci/cmd640.c
        (Noticed by Andrew Morton).
      
      * Improve some ->set_pio_mode comments.
      Reviewed-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      26bcb879
    • Bartlomiej Zolnierkiewicz's avatar
      ide: move ide_rate_filter() calls to the upper layer (take 2) · f212ff28
      Bartlomiej Zolnierkiewicz authored
      * 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: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      f212ff28
    • Bartlomiej Zolnierkiewicz's avatar
      ide: mode limiting fixes for user requested speed changes · 7670df73
      Bartlomiej Zolnierkiewicz authored
      * 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: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      7670df73
    • Sergei Shtylyov's avatar
      hpt366: MWDMA filter for SATA cards (take 2) · b4e44369
      Sergei Shtylyov authored
      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: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      b4e44369
  15. 11 Sep, 2007 2 commits
    • Sergei Shtylyov's avatar
      hpt366: UltraDMA filter for SATA cards (take 2) · 2808b0a9
      Sergei Shtylyov authored
      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: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Bob Ham <rah@bash.sh>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      2808b0a9
    • Sergei Shtylyov's avatar
      hpt366: fix PCI clock detection for HPT374 (take 4) · 72931368
      Sergei Shtylyov authored
      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: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      72931368