1. 16 10月, 2009 5 次提交
  2. 09 10月, 2009 1 次提交
  3. 07 10月, 2009 5 次提交
  4. 06 10月, 2009 7 次提交
  5. 21 9月, 2009 1 次提交
  6. 18 9月, 2009 6 次提交
    • J
      libata: Add pata_atp867x driver for Artop/Acard ATP867X controllers · d15d6e6c
      John(Jung-Ik) Lee 提交于
      This is a new pata driver for ARTOP 867X 64bit 4-channel UDMA133 ATA ctrls.
      Based on the Atp867 data sheet rev 1.2, Acard, and in part on early ide codes
      from Eric Uhrhane <ericu@google.com>.
      Signed-off-by: NJohn(Jung-Ik) Lee <jilee@google.com>
      Reviewed-by: NGrant Grundler <grundler@google.com>
      Reviewed-by: NGwendal Gringo <gwendal@google.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      d15d6e6c
    • R
      pata_amd: do not filter out valid modes in nv_mode_filter · 90950a25
      Robert Hancock 提交于
      On a Compaq Presario V3000 laptop (NVIDIA MCP51 chipset), pata_amd selects
      PIO0 mode for the PATA DVD-RAM drive instead of MWDMA2 which it supports:
      
      ata4.00: ATAPI: HL-DT-ST DVDRAM GSA-4084N, KQ09, max MWDMA2
      ata4: nv_mode_filter: 0x39f&0x7001->0x1, BIOS=0x0 (0x0) ACPI=0x7001 (60:600:0x11)
      ata4.00: configured for PIO0
      
      For some reason, the BIOS-set UDMA configuration returns 0 and the ACPI _GTM
      reports that UDMA2 and PIO0 are enabled. This causes nv_mode_filter to end up
      allowing only PIO0 and UDMA0-2. Since the drive doesn't support UDMA we end up
      using PIO0.
      
      Since the controllers should always support PIO4, MWDMA2 and UDMA2 regardless
      of what cable type is used, let's make sure we don't filter out these modes
      regardless of what wacky settings the BIOS is using.
      Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      90950a25
    • M
      sata_promise: update reset code · ff7cddf5
      Mikael Pettersson 提交于
      sata_promise's reset code has deviated quite a bit from
      the Promise reference driver's, and it has been observed
      to fail to recover from errors in some cases.
      
      This patch thus updates the reset code to more closely
      match the reference driver:
      
      - soft reset (pdc_reset_port):
        * wait for ATA engine to not be in packet command mode
          (2nd gen only)
        * write reset bit in PDC_CTLSTAT before the first read
          in the loop
        * for 2nd gen SATA follow up with FPDMA reset and clearing
          error status registers
      - hard reset (pdc_sata_hardreset):
        * wait for ATA engine to not be in packet command mode
          (2nd gen only)
        * reset ATA engine via the PCI control register
        * Tejun's change to use non-waiting hardreset + follow-up SRST
      
      I'm not changing the hotplug mask bits since they are taken care
      of by sata_promise's ->freeze() and ->thaw() operations. And I'm
      not writing the PMP port # because that's always zero (for now).
      
      Tested here on various controllers. In particular, one disk
      which used to timeout and fail to recover from certain hdparm
      and smartmonctl commands now works nicely.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      ff7cddf5
    • M
      sata_promise: disable hotplug on 1st gen chips · 0ae6654d
      Mikael Pettersson 提交于
      1st generation Promise SATA chips are prone to generating spurious
      hotplug events which can disrupt normal operation. This has been
      observed on 20376 and 20378 chips. This patch thus disables hotplug
      support on 1st gen chips while leaving it enabled for 2nd gen chips.
      
      The pdc_sata_hotplug_offset() function becomes redundant so it is
      removed.
      
      Tested on 1st gen 20376 and 20378 mainboard chips and on a 2nd gen
      SATA300 PCI card.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Tested-by: NKurt Roeckx <kurt@roeckx.be>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      0ae6654d
    • T
      libata: fix spurious WARN_ON_ONCE() on port freeze · 4dc738ed
      Tejun Heo 提交于
      Commit 54c38444 makes libata abort qcs
      after the port is frozen.  This is necessary to guarantee that TF
      registers are accessed after the DMA engine is shutdown after an
      error.  However, this triggers WARN_ON_ONCE() check in
      ata_qc_complete() spuriously.  Move WARN_ON_ONCE() downwards such that
      failing commands while frozen doesn't trigger it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      4dc738ed
    • T
      ahci: restore pci_intx() handling · 31b239ad
      Tejun Heo 提交于
      Commit a5bfc471 dropped explicit
      pci_intx() manipulation from ahci because it seemed unnecessary and
      ahci doesn't seem to be the right place to be tweaking it if it were.
      This was largely okay but there are exceptions.  There was one on an
      embedded platform which was fixed via firmware and now bko#14124
      reports it on a HP DL320.
      
        http://bugzilla.kernel.org/show_bug.cgi?id=14124
      
      I still think this isn't something libata drivers should be caring
      about (the only ones which are calling pci_intx() explicitly are
      libata ones and one other driver) but for now reverting the change
      seems to be the right thing to do.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NThomas Jarosch <thomas.jarosch@intra2net.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      31b239ad
  7. 11 9月, 2009 5 次提交
  8. 09 9月, 2009 8 次提交
  9. 02 9月, 2009 2 次提交
    • R
      sata_sil24: always set protocol override for non-ATAPI data commands · 4f1a0ee1
      Robert Hancock 提交于
      The sil24 hardware has a built-in list of commands and associated protocols
      that gets used by default to decide how to handle a given command. However,
      if the command is not known to the controller then it presumably assumes it to
      be a non-data command which then causes protocol mismatch errors if the device
      ends up requesting data transfer. The new DATA SET MANAGEMENT - Trim command
      causes this issue since it's a DMA data-out command.
      
      Since we should always know best what protocol the command should be using,
      let's just set the override flag to inform the controller what protocol to use
      for all non-ATAPI commands with data transfer.
      Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
      Tested-by: NMark Lord <liml@rtr.ca>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      4f1a0ee1
    • M
      libata: Export AHCI capabilities · 77cdec1a
      Matthew Garrett 提交于
      AHCI exports various capability bits that may be of interest to userspace
      such as whether the BIOS claims a port is hotpluggable or eSATA. Providing
      these via sysfs along with the version of the AHCI spec implemented by
      the host allows userspace to make policy decisions for things like ALPM.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      77cdec1a