Skip to content

L
linux-davinci
Switch branch/tag
  1. 18 Sep, 2009 34 commits
  3. 17 Sep, 2009 6 commits
    • H. Peter Anvin's avatar
      Merge branch 'x86/pat' into x86/urgent · 3bb045f1
      H. Peter Anvin authored 
      Merge reason:

Suresh Siddha (1):
      x86, pat: don't use rb-tree based lookup in reserve_memtype()

... requires previous x86/pat commits already pushed to Linus.
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      3bb045f1
    • Suresh Siddha's avatar
      x86, pat: don't use rb-tree based lookup in reserve_memtype() · dcb73bf4
      Suresh Siddha authored 
      Recent enhancement of rb-tree based lookup exposed a  bug with the lookup
mechanism in the reserve_memtype() which ensures that there are no conflicting
memtype requests for the memory range.

memtype_rb_search() returns an entry which has a start address <= new start
address. And from here we traverse the linear linked list to check if there
any conflicts with the existing mappings. As the rbtree is based on the
start address of the memory range, it is quite possible that we have several
overlapped mappings whose start address is much less than new requested start
but the end is >= new requested end. This results in conflicting memtype
mappings.

Same bug exists with the old code which uses cached_entry from where
we traverse the linear linked list. But the new rb-tree code exposes this
bug fairly easily.

For now, don't use the memtype_rb_search() and always start the search from
the head of linear linked list in reserve_memtype(). Linear linked list
for most of the systems grow's to few 10's of entries(as we track memory type
of RAM pages using struct page). So we should be ok for now.

We still retain the rbtree and use it to speed up free_memtype() which
doesn't have the same bug(as we know what exactly we are searching for
in free_memtype).

Also use list_for_each_entry_from() in free_memtype() so that we start
the search from rb-tree lookup result.
Reported-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
LKML-Reference: <1253136483.4119.12.camel@sbs-t61.sc.intel.com>
Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      dcb73bf4
    • John(Jung-Ik) Lee's avatar
      libata: Add pata_atp867x driver for Artop/Acard ATP867X controllers · d15d6e6c
      John(Jung-Ik) Lee authored 
      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: default avatarJohn(Jung-Ik) Lee <jilee@google.com>
Reviewed-by: default avatarGrant Grundler <grundler@google.com>
Reviewed-by: default avatarGwendal Gringo <gwendal@google.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      d15d6e6c
    • Robert Hancock's avatar
      pata_amd: do not filter out valid modes in nv_mode_filter · 90950a25
      Robert Hancock authored 
      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: default avatarRobert Hancock <hancockrwd@gmail.com>
Cc: stable@kernel.org
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      90950a25
    • Mikael Pettersson's avatar
      sata_promise: update reset code · ff7cddf5
      Mikael Pettersson authored 
      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: default avatarMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      ff7cddf5
    • Mikael Pettersson's avatar
      sata_promise: disable hotplug on 1st gen chips · 0ae6654d
      Mikael Pettersson authored 
      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: default avatarMikael Pettersson <mikpe@it.uu.se>
Tested-by: default avatarKurt Roeckx <kurt@roeckx.be>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      0ae6654d