22 Oct, 2010

2 commits

  • The current LPM implementation has the following issues.

    * Operation order isn't well thought-out. e.g. HIPM should be
    configured after IPM in SControl is properly configured. Not the
    other way around.

    * Suspend/resume paths call ata_lpm_enable/disable() which must only
    be called from EH context directly. Also, ata_lpm_enable/disable()
    were called whether LPM was in use or not.

    * Implementation is per-port when it should be per-link. As a result,
    it can't be used for controllers with slave links or PMP.

    * LPM state isn't managed consistently. After a link reset for
    whatever reason including suspend/resume the actual LPM state would
    be reset leaving ap->lpm_policy inconsistent.

    * Generic/driver-specific logic boundary isn't clear. Currently,
    libahci has to mangle stuff which libata EH proper should be
    handling. This makes the implementation unnecessarily complex and
    fragile.

    * Tied to ALPM. Doesn't consider DIPM only cases and doesn't check
    whether the device allows HIPM.

    * Error handling isn't implemented.

    Given the extent of mismatch with the rest of libata, I don't think
    trying to fix it piecewise makes much sense. This patch reimplements
    LPM support.

    * The new implementation is per-link. The target policy is still
    port-wide (ap->target_lpm_policy) but all the mechanisms and states
    are per-link and integrate well with the rest of link abstraction
    and can work with slave and PMP links.

    * Core EH has proper control of LPM state. LPM state is reconfigured
    when and only when reconfiguration is necessary. It makes sure that
    LPM state is reset when probing for new device on the link.
    Controller agnostic logic is now implemented in libata EH proper and
    driver implementation only has to deal with controller specifics.

    * Proper error handling. LPM config failure is attributed to the
    device on the link and LPM is disabled for the link if it fails
    repeatedly.

    * ops->enable/disable_pm() are replaced with single ops->set_lpm()
    which takes @policy and @hints. This simplifies driver specific
    implementation.

    Signed-off-by: Tejun Heo
    Signed-off-by: Jeff Garzik

    Tejun Heo
     
  • Link power management related symbols are in confusing state w/ mixed
    usages of lpm, ipm and pm. This patch cleans up lpm related symbols
    and sysfs show/store functions as follows.

    * lpm states - NOT_AVAILABLE, MIN_POWER, MAX_PERFORMANCE and
    MEDIUM_POWER are renamed to ATA_LPM_UNKNOWN and
    ATA_LPM_{MIN|MAX|MED}_POWER.

    * Pre/postfixes are unified to lpm.

    * sysfs show/store functions for link_power_management_policy were
    curiously named get/put and unnecessarily complex. Renamed to
    show/store and simplified.

    Signed-off-by: Tejun Heo
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

29 Sep, 2010

1 commit

  • libata depends on scsi_host_template for module reference counting and
    sht's should be owned by each low level driver. During libahci split,
    the sht was left with libahci.ko leaving the actual low level drivers
    not reference counted. This made ahci and ahci_platform always
    unloadable even while they're being actively used.

    Fix it by defining AHCI_SHT() macro in ahci.h and defining a sht for
    each low level ahci driver.

    stable: only applicable to 2.6.35.

    Signed-off-by: Tejun Heo
    Reported-by: Pedro Francisco
    Tested-by: Michael Tokarev
    Cc: stable@kernel.org
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

10 Sep, 2010

1 commit


26 Aug, 2010

1 commit


02 Aug, 2010

1 commit


02 Jul, 2010

1 commit

  • For yet unknown reason, MCP89 on MBP 7,1 doesn't work w/ ahci under
    linux but the controller doesn't require explicit mode setting and
    works fine with ata_generic. Make ahci ignore the controller on MBP
    7,1 and let ata_generic take it for now.

    Reported in bko#15923.

    https://bugzilla.kernel.org/show_bug.cgi?id=15923

    NVIDIA is investigating why ahci mode doesn't work.

    Signed-off-by: Tejun Heo
    Cc: Peer Chen
    Cc: stable@kernel.org
    Reported-by: Anders Østhus
    Reported-by: Andreas Graf
    Reported-by: Benoit Gschwind
    Reported-by: Damien Cassou
    Reported-by: tixetsal@juno.com
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

15 May, 2010

12 commits


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

18 Mar, 2010

3 commits

  • pp->active_link is not reliable when FBS is enabled.
    Both PORT_SCR_ACT and PORT_CMD_ISSUE should be checked
    because mixed NCQ and non-NCQ commands may be in flight.

    Signed-off-by: Shane Huang
    Signed-off-by: Jeff Garzik

    Shane Huang
     
  • HP is recycling both DMI_PRODUCT_NAME and DMI_BIOS_VERSION making
    ahci_broken_suspend() trigger for later products which are not
    affected by the original problems. Match BIOS date instead of version
    and add references to bko's so that full information can be found
    easier later.

    This fixes http://bugzilla.kernel.org/show_bug.cgi?id=15462

    Signed-off-by: Tejun Heo
    Reported-by: tigerfishdaisy@gmail.com
    Signed-off-by: Jeff Garzik

    Tejun Heo
     
  • bko#15481 shows that we're missing some NVIDIA ahci PCI IDs. Peer
    Chen confirms that IDs 0x580-0x58f are reserved for cases where Linux
    ID option is selected in the BIOS and are only used for mcp65-73. Add
    0x0581-0x058f.

    http://bugzilla.kernel.org/show_bug.cgi?id=15481

    Signed-off-by: Tejun Heo
    Cc: Peer Chen
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

02 Mar, 2010

3 commits


25 Feb, 2010

1 commit

  • Mike Cui reported that his system with an NVIDIA MCP79 (aka MCP7A)
    chipset stopped working with 2.6.32. The problem appears to be that
    2.6.32 now enables the FPDMA auto-activate optimization in the ahci
    driver. The drive works fine with this enabled on an Intel AHCI so
    this appears to be a chipset bug. Since MCP79 is a fairly recent
    NVIDIA chipset and we don't have any info on whether any other NVIDIA
    chipsets have this issue, disable FPDMA AA optimization on all NVIDIA
    AHCI controllers for now.

    Should address http://bugzilla.kernel.org/show_bug.cgi?id=14922

    Signed-off-by: Robert Hancock
    While-we-investigate-issue-this-patch-looks-good-to-me-by:
    Prajakta Gudadhe
    Signed-off-by: Jeff Garzik
    Cc: stable@kernel.org

    Robert Hancock
     

04 Feb, 2010

1 commit

  • Acer G725 shares the same suspend problem with the HP laptops which
    lose ATA devices on resume. New firmware which fixes the problem is
    already available. Add G725 with old firmwares to the broken suspend
    list.

    This problem has been reported in bko#15104.

    http://bugzilla.kernel.org/show_bug.cgi?id=15104

    Signed-off-by: Tejun Heo
    Reported-by: Jani-Matti Hätinen
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

04 Dec, 2009

1 commit

  • ahci can drive the Promise PDC42819, but obviously it can only use SATA
    disks connected to this controller. The controller can actually support
    SAS disks as well, but we only know how to use it in it's AHCI mode.

    Add a message to let users know that because ahci is driving their chip
    they can only use the SATA disks connected to this controller.

    Signed-off-by: Mark Nelson
    Signed-off-by: Jeff Garzik

    Mark Nelson
     

03 Dec, 2009

1 commit

  • I obseved there is a sata_async_notification() for every ahci
    interrupt. But the async notification does nothing (this is hard
    disk drive and no pmp). This cause cpu wastes some time on sntf
    register access.

    It appears ICH AHCI doesn't support SNotification register, but the
    controller reports it does. After quirking it, the async notification
    disappears.

    PS. it appears all ICH don't support SNotification register from ICH
    manual, don't know if we need quirk all ICH. I don't have machines
    with all kinds of ICH.

    Signed-off-by: Shaohua Li
    Signed-off-by: Jeff Garzik

    Shaohua Li
     

04 Nov, 2009

1 commit


16 Oct, 2009

2 commits


09 Oct, 2009

1 commit

  • Commit f80ae7e45a0e03da188494c6e947a5c8b0cdfb4a
    ahci: filter FPDMA non-zero offset enable for Aspire 3810T
    breaks the current git build for configurations that don't define
    CONFIG_ATA_ACPI.
    This adds an ifdef wrapper to ahci_gtf_filter_workaround.

    Signed-off-by: Markus Trippelsdorf
    Acked-by: Tejun Heo
    Signed-off-by: Jeff Garzik

    Markus Trippelsdorf
     

06 Oct, 2009

3 commits

  • Curiously, Aspire 3810T issues many SATA feature enable commands via
    _GTF, of which one is invalid and another is not supported by the
    drive. In the process, it also enables FPDMA non-zero offset.
    However, the feature also needs to be supported and enabled from the
    controller and it's wrong to enable it from _GTF unless the controller
    can do it by default.

    Currently, this ends up enabling FPDMA non-zero offset only on the
    drive side leading to NCQ command failures and eventual disabling of
    NCQ. This patch makes libata filter out FPDMA non-zero offset enable
    for the machine.

    This was reported by Marcus Meissner in bnc#522790.

    https://bugzilla.novell.com/show_bug.cgi?id=522790

    Reported-by: Marcus Meissner

    Signed-off-by: Jeff Garzik

    Tejun Heo
     
  • Update the AHCI driver to display all of the HBA capabilities defined in the
    AHCI 1.3 specification. Some of these are in a new CAP2 (HBA Capabilities
    Extended) register which is only defined on AHCI 1.2 or later. The spec says
    that undefined registers should always return 0 on read, but to be safe we
    assume a value of 0 unless the controller reports AHCI version 1.2 or later.
    The value can also be retrieved through sysfs as with the existing capability
    field.

    For example, on an Intel Ibex Peak (PCH) controller:

    ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part ems
    sxs apst

    We don't do anything special with the new flags yet.

    Also, change the code that displays the flags to use the same bit enumerations
    that are used to control actual operation.

    Signed-off-by: Robert Hancock
    Signed-off-by: Jeff Garzik

    Robert Hancock
     
  • Till now only one board, ASUS M2A-VM, can do 64bit dma with recent
    BIOSen. Enabling 64bit DMA by default already broke three boards.
    Enabling 64bit DMA isn't worth these regressions. Disable 64bit DMA
    by default and enable it only on boards which are known to work.

    Signed-off-by: Tejun Heo
    Reported-by: Gabriele Balducci
    Reported-by: maierp@informatik.tu-muenchen.de
    Cc: Shane Huang
    Cc: stable@kernel.org
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

18 Sep, 2009

1 commit

  • Commit a5bfc4714b3f01365aef89a92673f2ceb1ccf246 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: Tejun Heo
    Reported-by: Thomas Jarosch
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

11 Sep, 2009

2 commits