1. 05 2月, 2008 1 次提交
    • D
      intel-agp: add chipset flushing support · 6c00a61e
      Dave Airlie 提交于
      This adds support for flushing the chipsets on the 915, 945, 965 and G33
      families of Intel chips.
      
      The BIOS doesn't seem to always allocate the BAR on the 965 chipsets
      so I have to use pci resource code to create a resource
      
      It adds an export for pcibios_align_resource.
      6c00a61e
  2. 13 10月, 2007 2 次提交
  3. 11 10月, 2007 1 次提交
  4. 03 5月, 2007 1 次提交
  5. 02 12月, 2006 1 次提交
  6. 03 11月, 2006 1 次提交
  7. 28 6月, 2006 1 次提交
  8. 26 6月, 2006 1 次提交
  9. 22 6月, 2006 1 次提交
    • R
      [PATCH] PCI: i386/x86_84: disable PCI resource decode on device disable · 53e4d30d
      Rajesh Shah 提交于
      When a PCI device is disabled via pci_disable_device(), it's still
      left decoding its BAR resource ranges even though its driver
      will have likely released those regions (and may even have
      unloaded). pci_enable_device() already explicitly enables
      BAR resource decode for the device being enabled. This patch
      disables resource decode for the PCI device being disabled,
      making it symmetric with the enable call.
      
      I saw this while doing something else, not because of a
      problem report. Still, seems to be the correct thing to do.
      Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      53e4d30d
  10. 24 11月, 2005 1 次提交
  11. 09 9月, 2005 1 次提交
  12. 31 8月, 2005 1 次提交
    • I
      [PATCH] x86: pci_assign_unassigned_resources() update · 81d4af13
      Ivan Kokshaysky 提交于
      I had some time to think about PCI assign issues in 2.6.13-rc series.
      
      The major problem here is that we call pci_assign_unassigned_resources()
      way too early - at subsys_initcall level. Therefore we give no chances
      to ACPI and PnP routines (called at fs_initcall level) to reserve their
      respective resources properly, as the comments in drivers/pnp/system.c
      and drivers/acpi/motherboard.c suggest:
      
       /**
        * Reserve motherboard resources after PCI claim BARs,
        * but before PCI assign resources for uninitialized PCI devices
        */
      
      So I moved the pci_assign_unassigned_resources() call to
      pcibios_assign_resources() (fs_initcall), which should hopefully fix a
      lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary.
      
      Other changes:
      - remove resource assignment code from pcibios_assign_resources(), since
        it duplicates pci_assign_unassigned_resources() functionality and
        actually does nothing in 2.6.13;
      - modify ROM assignment code as per Ben's suggestion: try to use firmware
        settings by default (if PCI_ASSIGN_ROMS is not set);
      - set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for
        various setups.
      
      Confirmed by Tero Roponen <teanropo@cc.jyu.fi> (who had problems with
      the 4kB CardBus IO size previously).
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      81d4af13
  13. 02 7月, 2005 1 次提交
    • I
      [PATCH] PCI: pci_assign_unassigned_resources() on x86 · 299de034
      Ivan Kokshaysky 提交于
      - Add sanity check for io[port,mem]_resource in setup-bus.c. These
        resources look like "free" as they have no parents, but obviously
        we must not touch them.
      - In i386.c:pci_allocate_bus_resources(), if a bridge resource cannot be
        allocated for some reason, then clear its flags. This prevents any child
        allocations in this range, so the setup-bus code will work with a clean
        resource sub-tree.
      - i386.c:pcibios_enable_resources() doesn't enable bridges, as it checks
        only resources 0-5, which looks like a clear bug to me. I suspect it
        might break hotplug as well in some cases.
      
      From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      299de034
  14. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4