1. 30 Apr, 2008 1 commit
    • Suresh Siddha's avatar
      x86 PAT: fix performance drop for glx, use UC minus for ioremap(),... · de33c442
      Suresh Siddha authored
      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: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      de33c442
  2. 20 Apr, 2008 1 commit
  3. 17 Apr, 2008 2 commits
  4. 04 Feb, 2008 1 commit
    • Dave Airlie's avatar
      intel-agp: add chipset flushing support · 6c00a61e
      Dave Airlie authored
      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
  5. 12 Oct, 2007 2 commits
  6. 11 Oct, 2007 1 commit
  7. 02 May, 2007 1 commit
  8. 01 Dec, 2006 1 commit
  9. 03 Nov, 2006 1 commit
  10. 27 Jun, 2006 1 commit
  11. 25 Jun, 2006 1 commit
  12. 21 Jun, 2006 1 commit
    • Rajesh Shah's avatar
      [PATCH] PCI: i386/x86_84: disable PCI resource decode on device disable · 53e4d30d
      Rajesh Shah authored
      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: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      53e4d30d
  13. 24 Nov, 2005 1 commit
  14. 08 Sep, 2005 1 commit
  15. 30 Aug, 2005 1 commit
    • Ivan Kokshaysky's avatar
      [PATCH] x86: pci_assign_unassigned_resources() update · 81d4af13
      Ivan Kokshaysky authored
      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: default avatarLinus Torvalds <torvalds@osdl.org>
      81d4af13
  16. 01 Jul, 2005 1 commit
    • Ivan Kokshaysky's avatar
      [PATCH] PCI: pci_assign_unassigned_resources() on x86 · 299de034
      Ivan Kokshaysky authored
      - 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: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      299de034
  17. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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