1. 28 10月, 2006 2 次提交
  2. 24 10月, 2006 1 次提交
    • L
      Revert unintentional and bogus change to drivers/pci/quirks.c · 0c0e4668
      Linus Torvalds 提交于
      In commit 4e8a5201 ("[PKT_SCHED] netem:
      Orphan SKB when adding to queue.") Davem mistakenly also included a
      temporary diff in his tree that disabled the pci_fixup_video VGA quirk,
      which broke sparc64.
      
      This reverts that part of the commit. Sayeth Davem:
      
        "Greg KH has a patch coming to you soon which will move that VGA code
         back into x86/x86_64/IA64 specific areas and will fix the sparc64
         problem properly."
      
      Special thanks to Claudio Martins <ctpm@ist.utl.pt> for noticing the
      error in the first place.
      
      Cc: Claudio Martins <ctpm@ist.utl.pt>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0c0e4668
  3. 23 10月, 2006 1 次提交
  4. 19 10月, 2006 4 次提交
  5. 01 10月, 2006 1 次提交
    • A
      [PATCH] PCI quirks update · 236561e5
      Alan Cox 提交于
      This fixes two things
      
      Firstly someone mistakenly used "errata" for the singular.  This causes
      Dave Woodhouse to emit diagnostics whenever the string is read, and so
      should be fixed.
      
      Secondly the AMD AGP tunnel has an erratum which causes hangs if you try
      and do direct PCI to AGP transfers in some cases.  We have a flag for
      PCI/PCI failures but we need a different flag for this really as in this
      case we don't want to stop PCI/PCI transfers using things like IOAT and the
      new RAID offload work.
      
      I'll post some updates to make proper use of the PCIAGP flag in the
      media/video drivers to Mauro.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      236561e5
  6. 27 9月, 2006 2 次提交
  7. 01 9月, 2006 1 次提交
  8. 27 8月, 2006 1 次提交
  9. 20 8月, 2006 1 次提交
  10. 04 8月, 2006 1 次提交
  11. 26 7月, 2006 1 次提交
  12. 13 7月, 2006 3 次提交
    • K
      [PATCH] PCI: PCIE power management quirk · ffadcc2f
      Kristen Carlson Accardi 提交于
      When changing power states from D0->DX and then from DX->D0, some
      Intel PCIE chipsets will cause a device reset to occur.  This will
      cause problems for any D State other than D3, since any state
      information that the driver will expect to be present coming from
      a D1 or D2 state will have been cleared.  This patch addes a
      flag to the pci_dev structure to indicate that devices should
      not use states D1 or D2, and will set that flag for the affected
      chipsets.  This patch also modifies pci_set_power_state() so that
      when a device driver tries to set the power state on
      a device that is downstream from an affected chipset, or on one
      of the affected devices it only allows state changes to or
      from D0 & D3.  In addition, this patch allows the delay time
      between D3->D0 to be changed via a quirk.  These chipsets also
      need additional time to change states beyond the normal 10ms.
      Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ffadcc2f
    • M
      [PATCH] PCI: Clear abnormal poweroff flag on VIA southbridges, fix resume · 709cf5ea
      Matthew Garrett 提交于
      Some VIA southbridges contain a flag in the ACPI register space that
      indicates whether an abnormal poweroff has occured, presumably with the
      intention that it can be cleared on clean shutdown.  Some BIOSes check this
      flag at resume time, and will re-POST the system rather than jump back to
      the OS if it's set.  Clearing it at boot time appears to be sufficient.
      I'm not sure if drivers/pci/quirks.c is the right place to do it, but I'm
      not sure where would be cleaner.
      
      [akpm@osdl.org: cleanups, build fix]
      Signed-off-by: NMatthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: "Brown, Len" <len.brown@intel.com>
      Cc: "Yu, Luming" <luming.yu@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      709cf5ea
    • A
      [PATCH] ide: fix Jmicron support · 15e0c694
      Alan Cox 提交于
      Prior to 2.6.18rc1 you could install with devices on a JMicron chipset
      using the "all-generic-ide" option. As of this kernel the AHCI driver
      grabs the controller and rams it into AHCI mode losing the PATA ports
      and making CD drives and the like vanish. The all-generic-ide option
      fails because the AHCI driver grabbed the PCI device and reconfigured
      it.
      
      To fix this three things are needed.
      
      #1 We must put the chip into dual function mode
      #2 The AHCI driver must grab only function 0 (already in your rc1 tree)
      #3 Something must grab the PATA ports
      
      The attached patch is the minimal risk edition of this. It puts the chip
      into dual function mode so that AHCI will grab the SATA ports without
      losing the PATA ports. To keep the risk as low as possible the third
      patch adds the PCI identifiers for the PATA port and the FN check to the
      ide-generic driver. There is a more featured jmicron driver on its way
      but that adds risk and the ide-generic support is sufficient to install
      and run a system.
      
      The actual chip setup done by the quirk is the precise setup recommended
      by the vendor.
      
      (The JMB368 appears only in the ide-generic entry as it has no AHCI so
      does not need the quirk)
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Acked-by: NJeff Garzik <jgarzik@pobox.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      15e0c694
  13. 12 7月, 2006 1 次提交
    • L
      Add PIIX4 APCI quirk for the 440MX chipset too · c6764664
      Linus Torvalds 提交于
      This is confirmed to fix a hang due to PCI resource conflicts with
      setting up the Cardbus bridge on old laptops with the 440MX chipsets.
      Original report by Alessio Sangalli, lspci debugging help by Pekka
      Enberg, and trial patch suggested by Daniel Ritz:
      
        "From the docs available i would _guess_ this thing is really similar
         to the 82443BX/82371AB combination.  at least the SMBus base address
         register is hidden at the very same place (32bit at 0x90 in function
         3 of the "south" brigde)"
      
      The dang thing is largely undocumented, but the patch was corroborated
      by Asit Mallick:
      
        "I am trying to find the register information. 440MX is an integration of
         440BX north-bridge without AGP and PIIX4E (82371EB).  PIIX4 quirk
         should cover the ACPI and SMBus related I/O registers."
      
      and verified to fix the problem by Alessio.
      
      Cc: Daniel Ritz <daniel.ritz-ml@swissonline.ch>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Dmitry Torokhov <dtor_core@ameritech.net>
      Tested-by: NAlessio Sangalli <alesan@manoweb.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c6764664
  14. 01 7月, 2006 1 次提交
  15. 22 6月, 2006 3 次提交
  16. 16 5月, 2006 2 次提交
  17. 28 4月, 2006 1 次提交
  18. 20 4月, 2006 1 次提交
  19. 15 4月, 2006 2 次提交
  20. 24 3月, 2006 4 次提交
  21. 18 1月, 2006 1 次提交
  22. 10 1月, 2006 1 次提交
    • D
      [PATCH] PCI Quirk: 1K I/O space granularity on Intel P64H2 · 9d265124
      Daniel Yeisley 提交于
      I've implemented a quirk to take advantage of the 1KB I/O space
      granularity option on the Intel P64H2 PCI Bridge.  I had to change
      probe.c because it sets the resource start and end to be aligned on 4k
      boundaries (after the quirk sets them to 1k boundaries).  I've tested
      this patch on a Unisys ES7000-600 both with and without the 1KB option
      enabled.  I also tested this on a 2 processor Dell box that doesn't have
      a P64H2 to make sure there were no negative affects there.
      Signed-off-by: NDan Yeisley <dan.yeisley@unisys.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9d265124
  23. 13 12月, 2005 1 次提交
    • J
      [PATCH] add boot option to control Intel SATA/PATA combined mode · 2bd0fa3b
      Jesse Barnes 提交于
      Combined mode sucks.  Especially when both libata and the legacy IDE
      drivers try to drive ports on the same device, since that makes DMA
      rather difficult.
      
      This patch addresses the problem by allowing the user to control which
      driver binds to the ports in a combined mode configuration.  In many
      cases, they'll probably want the libata driver to control both ports
      since it can use DMA for talking with ATAPI devices (when
      libata.atapi_enabled=1 of course).  It also allows the user to get old
      school behavior by letting the legacy IDE driver bind to both ports.
      But neither is forced, the patch doesn't change current behavior unless
      one of combined_mode=ide or combined_mode=libata is passed
      on the boot line.  Either of those options may require you to access
      your devices via different device nodes (/dev/hd* in the ide case
      and /dev/sd* in the libata case), though of course if you have udev
      installed nicely you may not notice anything.  :)
      
      Let me know if the documentation is too cryptic, I'd be happy to expand
      on it if necessary.  I think most users will want to boot with
      'combined_mode=libata' and add 'options libata atapi_enabled=1'
      to their modules.conf to get good DVD playing and disk behavior
      (haven't tested CD or DVD writing though).
      
      I'd much rather things behave sanely by default (i.e. DMA for devices on
      both ports), but apparently that's difficult given the various chip
      bugs and hardware configs out there (not to mention that people's
      drives may suddenly change from /dev/hdc to /dev/sdb), so this boot
      option may be the correct long term fix.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      2bd0fa3b
  24. 11 11月, 2005 2 次提交
  25. 31 10月, 2005 1 次提交