linux-toradex.git/drivers/ata, branch tegra-10.9.9

ahci: add Acer G725 to broken suspend list

2010-02-23T15:37:56+00:00

commit cedc9bf906dae044443d403371c887affdb44168 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

Call flush_dcache_page after PIO data transfers in libata-sff.c

2010-02-23T15:37:55+00:00

commit 2d68b7fe55d9e19a8a868224ed0dfd6526568521 upstream.

flush_dcache_page() must be called after (!ATA_TFLAG_WRITE) the
data copying to avoid D-cache aliasing with user space or I-D cache
coherency issues (when reading data from an ATA device using PIO,
the kernel dirties the D-cache but there is no flush_dcache_page()
required on Harvard architectures).

Signed-off-by: Catalin Marinas 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: retry link resume if necessary

2010-02-09T12:50:57+00:00

commit 5040ab67a2c6d5710ba497dc52a8f7035729d7b0 upstream.

Interestingly, when SIDPR is used in ata_piix, writes to DET in
SControl sometimes get ignored leading to detection failure.  Update
sata_link_resume() such that it reads back SControl after clearing DET
and retry if it's not clear.

Signed-off-by: Tejun Heo 
Reported-by: fengxiangjun 
Reported-by: Jim Faulkner 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: retry FS IOs even if it has failed with AC_ERR_INVALID

2010-02-09T12:50:44+00:00

commit 534ead709235b967b659947c55d9130873a432c4 upstream.

libata currently doesn't retry if a command fails with AC_ERR_INVALID
assuming that retrying won't get it any further even if retried.
However, a failure may be classified as invalid through hardware
glitch (incorrect reading of the error register or firmware bug) and
there isn't whole lot to gain by not retrying as actually invalid
commands will be failed immediately.  Also, commands serving FS IOs
are extremely unlikely to be invalid.  Retry FS IOs even if it's
marked invalid.

Transient and incorrect invalid failure was seen while debugging
firmware related issue on Samsung n130 on bko#14314.

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

Signed-off-by: Tejun Heo 
Reported-by: Johannes Stezenbach 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

ata_piix: fix MWDMA handling on PIIX3

2010-01-28T23:02:16+00:00

commit 6938594374ee506e91a4c03117a034ea0ed66783 upstream.

Fix erroneous check for ap->udma_mask in do_pata_set_dmamode()
resulting in controller not being programmed properly for MWDMA.

Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

ahci: disable SNotification capability for ich8

2010-01-28T23:02:15+00:00

commit 1b677afda44f7882b7e257d6f025d006ec5d14f9 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

pata_cmd64x: fix overclocking of UDMA0-2 modes

2010-01-06T23:03:23+00:00

commit 509426bd46ad0903dca409803e0ee3d30f99f1e8 upstream.

adev->dma_mode stores the transfer mode value not UDMA mode number
so the condition in cmd64x_set_dmamode() is always true and the higher
UDMA clock is always selected.  This can potentially result in data
corruption when UDMA33 device is used, when 40-wire cable is used or
when the error recovery code decides to lower the device speed down.

The issue was introduced in the commit 6a40da0 ("libata cmd64x: whack
into a shape that looks like the documentation") which goes back to
kernel 2.6.20.

Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

pata_hpt3x2n: fix clock turnaround

2010-01-06T23:03:22+00:00

commit 256ace9bbd4cdb6d48d5f55d55d42fa20527fad1 upstream.

The clock turnaround code still doesn't work for several reasons:

- 'USE_DPLL' flag in 'ap->host->private_data' is never initialized
  or updated, so the driver can only set the chip to the DPLL clock
  mode, not the PCI mode;

- the driver doesn't serialize access to the channels depending on
  the current clock mode like the vendor drivers, so the clock
  turnaround is only executed "optionally", not always as it should be;

- the wrong ports are written to when hpt3x2n_set_clock() is called
  for the secondary channel;

- hpt3x2n_set_clock() can inadvertently enable the disabled channels
  when resetting the channel state machines.

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

pata_hpt{37x|3x2n}: fix timing register masks (take 2)

2009-12-18T22:03:48+00:00

commit 5600c70e576199a7552e1c0fff43f3fe16f5566e upstream.

These drivers inherited from the older 'hpt366' IDE driver the buggy timing
register masks in their set_piomode() metods. As a result, too low command
cycle active time is programmed for slow PIO modes.  Quite fortunately, it's
later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram
the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA
mode #N also reprograms already set PIO data timings, usually to MWDMA mode #
max(N, 2) timings...

However, the drivers added some breakage of their own too:  the bit that they
set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of
the command cycle setup time; also, setting it in DMA mode is wrong as this
bit is only for PIO actually and clearing it for PIO modes is not needed as
no mode in any timing table has it set...

Fix all this, inverting the masks while at it, like in the 'hpt366' and
'pata_hpt366' drivers; bump the drivers' versions, accounting for recent
patches that forgot to do it...

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

sata_fsl: Split hard and soft reset

2009-11-19T23:18:17+00:00

Split sata_fsl_softreset() into hard and soft resets to make
error-handling more efficient & device and PMP detection more
reliable.

Also includes fix for PMP support, driver tested with Sil3726,
Sil4726 & Exar PMP controllers.

[AV: Also fixes resuming from deep sleep on MPC8315 CPUs]

Signed-off-by: Jiang Yutang 
Signed-off-by: Anton Vorontsov 
Signed-off-by: Jeff Garzik