1. 11 6月, 2008 1 次提交
  2. 06 6月, 2008 2 次提交
    • B
      x86/PCI: add workaround for bug in ASUS A7V600 BIOS (rev 1005) · 9f67fd5d
      Bertram Felgenhauer 提交于
      This BIOS claims the VIA 8237 south bridge to be compatible with VIA 586,
      which it is not.
      
      Without this patch, I get the following warning while booting,
      among others,
      
      | PCI: Using IRQ router VIA [1106/3227] at 0000:00:11.0
      | ------------[ cut here ]------------
      | WARNING: at arch/x86/pci/irq.c:265 pirq_via586_get+0x4a/0x60()
      | Modules linked in:
      | Pid: 1, comm: swapper Not tainted 2.6.26-rc4-00015-g1ec7d99c #1
      |  [<c0119fd4>] warn_on_slowpath+0x54/0x70
      |  [<c02246e0>] ? vt_console_print+0x210/0x2b0
      |  [<c02244d0>] ? vt_console_print+0x0/0x2b0
      |  [<c011a413>] ? __call_console_drivers+0x43/0x60
      |  [<c011a482>] ? _call_console_drivers+0x52/0x80
      |  [<c011aa89>] ? release_console_sem+0x1c9/0x200
      |  [<c0291d21>] ? raw_pci_read+0x41/0x70
      |  [<c0291e8f>] ? pci_read+0x2f/0x40
      |  [<c029151a>] pirq_via586_get+0x4a/0x60
      |  [<c02914d0>] ? pirq_via586_get+0x0/0x60
      |  [<c029178d>] pcibios_lookup_irq+0x15d/0x430
      |  [<c03b895a>] pcibios_irq_init+0x17a/0x3e0
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a6763>] kernel_init+0x73/0x250
      |  [<c03b87e0>] ? pcibios_irq_init+0x0/0x3e0
      |  [<c0114d00>] ? schedule_tail+0x10/0x40
      |  [<c0102dee>] ? ret_from_fork+0x6/0x1c
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c010324b>] kernel_thread_helper+0x7/0x1c
      |  =======================
      | ---[ end trace 4eaa2a86a8e2da22 ]---
      
      and IRQ trouble later,
      
      | irq 10: nobody cared (try booting with the "irqpoll" option)
      
      Now that's an VIA 8237 chip, so pirq_via586_get shouldn't be called
      at all; adding this workaround to via_router_probe() fixes the
      problem for me.
      
      Amazingly I have a 2.6.23.8 kernel that somehow works fine ... I'll
      never understand why.
      Signed-off-by: NBertram Felgenhauer <int-e@gmx.de>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9f67fd5d
    • A
      PCI/x86: fix up PCI stuff so that PCI_GOANY supports OLPC · 2bdd1b03
      Andres Salomon 提交于
      Previously, one would have to specifically choose CONFIG_OLPC and
      CONFIG_PCI_GOOLPC in order to enable PCI_OLPC.  That doesn't really work
      for distro kernels, so this patch allows one to choose CONFIG_OLPC and
      CONFIG_PCI_GOANY in order to build in OLPC support in a generic kernel (as
      requested by Robert Millan).
      
      This also moves GOOLPC before GOANY in the menuconfig list.
      
      Finally, make pci_access_init return early if we detect OLPC hardware.
      There's no need to continue probing stuff, and pci_pcbios_init
      specifically trashes our settings (we didn't run into that before because
      PCI_GOANY wasn't supported).
      Signed-off-by: NAndres Salomon <dilinger@debian.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      2bdd1b03
  3. 20 5月, 2008 1 次提交
  4. 14 5月, 2008 1 次提交
  5. 11 5月, 2008 1 次提交
  6. 09 5月, 2008 1 次提交
  7. 06 5月, 2008 2 次提交
  8. 05 5月, 2008 1 次提交
    • T
      x86: undo visws/numaq build changes · 48b83d24
      Thomas Gleixner 提交于
      arch/x86/pci/Makefile_32 has a nasty detail. VISWS and NUMAQ build
      override the generic pci-y rules. This needs a proper cleanup, but
      that needs more thoughts. Undo
      
      commit 895d3093
          x86: numaq fix
          do not override the existing pci-y rule when adding visws or
          numaq rules.
      
      There is also a stupid init function ordering problem vs. acpi.o
      
      Add comments to the Makefile to avoid tripping over this again.
      
      Remove the srat stub code in discontig_32.c to allow a proper NUMAQ
      build.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      48b83d24
  9. 01 5月, 2008 2 次提交
    • I
      x86: numaq fix · 895d3093
      Ingo Molnar 提交于
      do not override the existing pci-y rule when adding visws or
      numaq rules.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      895d3093
    • S
      x86 PAT: fix performance drop for glx, use UC minus for ioremap(),... · de33c442
      Suresh Siddha 提交于
      x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()
      
      Use UC_MINUS for ioremap(), ioremap_nocache() instead of strong UC.
      Once all the X drivers move to ioremap_wc(), we can go back to strong
      UC semantics for ioremap() and ioremap_nocache().
      
      To avoid attribute aliasing issues, pci_mmap_page_range() will also
      use UC_MINUS for default non write-combining mapping request.
      
      Next steps:
      	a) change all the video drivers using ioremap() or ioremap_nocache()
      	   and adding WC MTTR using mttr_add() to ioremap_wc()
      
      	b) for strict usage, we can go back to strong uc semantics
      	   for ioremap() and ioremap_nocache() after some grace period for
      	   completing step-a.
      
      	c) user level X server needs to use the appropriate method for setting
      	   up WC mapping (like using resourceX_wc sysfs file instead of
      	   adding MTRR for WC and using /dev/mem or resourceX under /sys)
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      de33c442
  10. 30 4月, 2008 2 次提交
  11. 29 4月, 2008 1 次提交
  12. 27 4月, 2008 14 次提交
  13. 21 4月, 2008 5 次提交
    • B
      PCI: x86: use generic pci_enable_resources() · b81d988c
      Bjorn Helgaas 提交于
      Use the generic pci_enable_resources() instead of the arch-specific code.
      
      Unlike this arch-specific code, the generic version:
          - checks for resource collisions with "!r->parent"
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b81d988c
    • B
      PCI: remove "pci=routeirq" noise from dmesg · 657472e9
      Bjorn Helgaas 提交于
      The "pci=routeirq" option was added in 2004, and I don't get any valid
      reports anymore.  The option is still mentioned in kernel-parameters.txt.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      657472e9
    • G
      PCI: Include PCI domain in PCI bus names on x86/x86_64 · cb3576fa
      Gary Hade 提交于
      The PCI bus names included in /proc/iomem and /proc/ioports are
      of the form 'PCI Bus #XX' where XX is the bus number.  This patch
      changes the naming to 'PCI Bus XXXX:YY' where XXXX is the domain
      number and YY is the bus number.  For example, PCI bus 14 in
      domain 0 will show as 'PCI Bus 0000:14' instead of 'PCI Bus #14'.
      This change makes the naming consistent with other architectures
      such as ia64 where multiple PCI domain support has been around
      longer.
      Signed-off-by: NGary Hade <garyhade@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      cb3576fa
    • G
      PCI: remove pcibios_fixup_ghosts() · 6355f3d1
      Greg Kroah-Hartman 提交于
      This function was obviously never being used since early 2.5 days as any
      device that it would try to remove would never really be removed from
      the system due to the PCI device list being held in the driver core, not
      the general list of PCI devices.
      
      As we have not had a single report of a problem here in 4 years, I think
      it's safe to remove now.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6355f3d1
    • G
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      Greg Kroah-Hartman 提交于
      We currently keep 2 lists of PCI devices in the system, one in the
      driver core, and one all on its own.  This second list is sorted at boot
      time, in "BIOS" order, to try to remain compatible with older kernels
      (2.2 and earlier days).  There was also a "nosort" option to turn this
      sorting off, to remain compatible with even older kernel versions, but
      that just ends up being what we have been doing from 2.5 days...
      
      Unfortunately, the second list of devices is not really ever used to 
      determine the probing order of PCI devices or drivers[1].  That is done
      using the driver core list instead.  This change happened back in the
      early 2.5 days.
      
      Relying on BIOS ording for the binding of drivers to specific device
      names is problematic for many reasons, and userspace tools like udev
      exist to properly name devices in a persistant manner if that is needed,
      no reliance on the BIOS is needed.
      
      Matt Domsch and others at Dell noticed this back in 2006, and added a
      boot option to sort the PCI device lists (both of them) in a
      breadth-first manner to help remain compatible with the 2.4 order, if
      needed for any reason.  This option is not going away, as some systems
      rely on them.
      
      This patch removes the sorting of the internal PCI device list in "BIOS"
      mode, as it's not needed at all anymore, and hasn't for many years.
      I've also removed the PCI flags for this from some other arches that for
      some reason defined them, but never used them.
      
      This should not change the ordering of any drivers or device probing.
      
      [1] The old-style pci_get_device and pci_find_device() still used this
      sorting order, but there are very few drivers that use these functions,
      as they are deprecated for use in this manner.  If for some reason, a
      driver rely on the order and uses these functions, the breadth-first
      boot option will resolve any problem.
      
      Cc: Matt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
  14. 17 4月, 2008 6 次提交