linux-toradex.git/drivers/ata/libahci.c, branch v3.10.78

ahci: disabled FBS prior to issuing software reset

2013-12-04T18:56:13+00:00

commit 89dafa20f3daab5b3e0c13d0068a28e8e64e2102 upstream.

Tested with Marvell 88se9125, attached with one port mulitplier(5 ports)
and one disk, we will get following boot log messages if using current
code:

  ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
  ata8.15: Port Multiplier 1.2, 0x1b4b:0x9715 r160, 5 ports, feat 0x1/0x1f
  ahci 0000:03:00.0: FBS is enabled
  ata8.00: hard resetting link
  ata8.00: SATA link down (SStatus 0 SControl 330)
  ata8.01: hard resetting link
  ata8.01: SATA link down (SStatus 0 SControl 330)
  ata8.02: hard resetting link
  ata8.02: SATA link down (SStatus 0 SControl 330)
  ata8.03: hard resetting link
  ata8.03: SATA link up 6.0 Gbps (SStatus 133 SControl 133)
  ata8.04: hard resetting link
  ata8.04: failed to resume link (SControl 133)
  ata8.04: failed to read SCR 0 (Emask=0x40)
  ata8.04: failed to read SCR 0 (Emask=0x40)
  ata8.04: failed to read SCR 1 (Emask=0x40)
  ata8.04: failed to read SCR 0 (Emask=0x40)
  ata8.03: native sectors (2) is smaller than sectors (976773168)
  ata8.03: ATA-8: ST3500413AS, JC4B, max UDMA/133
  ata8.03: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
  ata8.03: configured for UDMA/133
  ata8.04: failed to IDENTIFY (I/O error, err_mask=0x100)
  ata8.15: hard resetting link
  ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
  ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
  ata8.15: PMP revalidation failed (errno=-19)
  ata8.15: hard resetting link
  ata8.15: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
  ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
  ata8.15: PMP revalidation failed (errno=-19)
  ata8.15: limiting SATA link speed to 3.0 Gbps
  ata8.15: hard resetting link
  ata8.15: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
  ata8.15: Port Multiplier vendor mismatch '0x1b4b' != '0x133'
  ata8.15: PMP revalidation failed (errno=-19)
  ata8.15: failed to recover PMP after 5 tries, giving up
  ata8.15: Port Multiplier detaching
  ata8.03: disabled
  ata8.00: disabled
  ata8: EH complete

The reason is that current detection code doesn't follow AHCI spec:

First,the port multiplier detection process look like this:

	ahci_hardreset(link, class, deadline)
	if (class == ATA_DEV_PMP) {
		sata_pmp_attach(dev)	/* will enable FBS */
		sata_pmp_init_links(ap, nr_ports);
		ata_for_each_link(link, ap, EDGE) {
			sata_std_hardreset(link, class, deadline);
			if (link_is_online)	/* do soft reset */
				ahci_softreset(link, class, deadline);
		}
	}
But, according to chapter 9.3.9 in AHCI spec: Prior to issuing software
reset, software shall clear PxCMD.ST to '0' and then clear PxFBS.EN to
'0'.

The patch test ok with kernel 3.11.1.

tj: Patch white space contaminated, applied manually with trivial
    updates.

Signed-off-by: Xiangliang Yu 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

ahci: remove pmp link online check in FBS EH

2013-07-22T01:21:31+00:00

commit 912b9ac683b112615d5605686f1dc086402ce9f7 upstream.

ata_link_online() check in ahci_error_intr() is unnecessary, it should
be removed otherwise may lead to lockup with FBS enabled PMP.
http://marc.info/?l=linux-ide&m=137050421603272&w=2

Reported-by: Yu Liu 
Signed-off-by: Shane Huang 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: update "Maintained by:" tags

2013-05-14T18:13:04+00:00

Jeff moved on to a greener pasture.

 s/Maintained by: Jeff Garzik/Maintained by: Tejun Heo/g

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

AHCI: Support multiple MSIs

2013-01-24T16:25:13+00:00

Take advantage of multiple MSIs implementation on x86 - on
systems with IRQ remapping AHCI ports not only get assigned
separate MSI vectors - but also separate IRQs. As result,
interrupts generated by different ports could be serviced on
different CPUs rather than on a single one.

In cases when number of allocated MSIs is less than requested
the Sharing Last MSI mode does not get used, no matter
implemented in hardware or not. Instead, the driver assumes the
advantage of multiple MSIs is negated and falls back to the
single MSI mode as if MRSM bit was set (some Intel chips
implement this strategy anyway - MRSM bit gets set even if the
number of allocated MSIs exceeds the number of implemented ports).

Signed-off-by: Alexander Gordeev 
Acked-by: Jeff Garzik 
Cc: Bjorn Helgaas 
Cc: Suresh Siddha 
Cc: Yinghai Lu 
Cc: Matthew Wilcox 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/15bf7ee314dd55f21ec7d2a01c47613cd8190a7c.1353324359.git.agordeev@redhat.com
Signed-off-by: Ingo Molnar

[libata] replace sata_settings with devslp_timing

2013-01-14T18:29:15+00:00

NCQ capability was used to check availability of SATA Settings page
from Identify Device Data Log, which contains DevSlp timing variables.
It does not work on some HDDs and leads to error messages.

IDENTIFY word 78 bit 5(Hardware Feature Control) can't work either
because it is only the sufficient condition of Identify Device data
log, not the necessary condition.

This patch replaced ata_device->sata_settings with ->devslp_timing
to only save DevSlp timing variables(8 bytes), instead of the whole
SATA Settings page(512 bytes).

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

Reported-by: Borislav Petkov 
Signed-off-by: Shane Huang 
Cc: stable@vger.kernel.org
Signed-off-by: Jeff Garzik

ahci: convert ata_link_printk() to ata_link_warn()

2012-12-14T14:38:50+00:00

Using ata_link_warn() instead of ata_link_printk().

Signed-off-by: Wei Yongjun 
Signed-off-by: Jeff Garzik

ahci: implement aggressive SATA device sleep support

2012-09-13T05:08:53+00:00

Device Sleep is a feature as described in AHCI 1.3.1 Technical Proposal.
This feature enables an HBA and SATA storage device to enter the DevSleep
interface state, enabling lower power SATA-based systems.

Aggressive Device Sleep enables the HBA to assert the DEVSLP signal as
soon as there are no commands outstanding to the device and the port
specific Device Sleep idle timer has expired. This enables autonomous
entry into the DevSleep interface state without waiting for software
in power sensitive systems.

This patch enables Aggressive Device Sleep only if both host controller
and device support it.

Tested on AMD reference board together with Device Sleep supported device
sample.

Signed-off-by: Shane Huang 
Reviewed-by: Aaron Lu 
Signed-off-by: Jeff Garzik

ahci: un-staticize ahci_dev_classify

2012-08-17T17:26:22+00:00

Make ahci_dev_classify available to the ahci platform driver for custom
hard reset function.

Signed-off-by: Rob Herring 
Signed-off-by: Jeff Garzik

ahci: add AHCI_HFLAG_DELAY_ENGINE host flag

2012-03-13T20:35:37+00:00

The following commit was intended to fix problems with specific AHCI
controller(s) that would become bricks if the AHCI specification was not
followed strictly (that is, if ahci_start_engine() was called while the
controller was in the wrong state):

    commit 7faa33da9b7add01db9f1ad92c6a5d9145e940a7
    ahci: start engine only during soft/hard resets

However, some devices currently have issues with that fix, so we must
implement a flag that delays the ahci_start_engine() call only for specific
controllers.

This commit simply introduces the flag, without enabling it in any driver.

Note that even when AHCI_HFLAG_DELAY_ENGINE is not enabled, this patch does
not constitue a full revert to commit 7faa33da; there is still a change in
behavior to the ahci_port_suspend() failure path.

Signed-off-by: Brian Norris 
Signed-off-by: Jeff Garzik 
Cc: stable@kernel.org

ahci: start engine only during soft/hard resets

2012-01-09T00:14:57+00:00

This is another attempt at fixing the same problem that 270dac35c2
(libata: ahci_start_engine compliant to AHCI spec) tried to solve.
Unfortunately, 270dac35c2 created regressions for a lot more common
controllers and got reverted.

This specific AHCI IP block becomes a brick if the DMA engine is
started while DRQ is set.  It is not possible to avoid the condition
completely but the most common occurrence is caused by spurious use of
ahci_start_engine() from ahci_start_port() during init sequence.

DMA engine is started after both soft and hard resets and
ahci_start_port() is always followed by resets, so there is no reason
to start DMA engine from ahci_start_port().

This patch removes ahci_start_engine() invocation from
ahci_start_port().  This change makes failure path of
ahci_port_suspend() leave engine stopped without following resets.
This is resolved by replacing ahci_start_port() call with
ata_port_freeze() which forces resets afterwards, which is the better
behavior anyway.

Signed-off-by: Tejun Heo 
Reported-by: Brian Norris 
Reported-by: Jian Peng 
Signed-off-by: Jeff Garzik