Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 9月, 2008 1 次提交
    • L
      Un-break printk strings in x86 PCI probing code · 011fec74
      由 Linus Torvalds 提交于 
      Breaking lines due to some imaginary problem with a long line length is
often stupid and wrong, but never more so when it splits a string that
is printed out into multiple lines.  This really ended up making it much
harder to find where some error strings were printed out, because a
simple 'grep' didn't work.

I'm sure there is tons more of this particular idiocy hiding in other
places, but this particular case hit me once more last week. So fix it.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      011fec74
  3. 30 8月, 2008 1 次提交
  5. 25 8月, 2008 1 次提交
    • Y
      x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3 · a2bd7274
      由 Yinghai Lu 提交于 
      David Witbrodt tracked down (and bisected) a hpet bootup hang on his
system to the following problem: a BIOS bug made the hpet device
visible as a generic PCI device. If e820 reserved entries happen to
be registered first in the resource tree [which v2.6.26 started doing],
then the PCI code will reallocate that device's BAR to some other
address - breaking timer IRQs and hanging the system.

( Normally hpet devices are hidden by the BIOS from the OS's PCI
  discovery via chipset magic. Sometimes the hpet is not a PCI device
  at all. )

Solve this fundamental fragility by making non-PCI platform drivers
insert resources into the resource tree even if it overlaps the e820
reserved entry, to keep the resource manager from updating the BAR.

Also do these checks for the ioapic and mmconfig addresses, and emit
a warning if this happens.
Bisected-by: NDavid Witbrodt <dawitbro@sbcglobal.net>
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Tested-by: NDavid Witbrodt <dawitbro@sbcglobal.net>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a2bd7274
  7. 29 7月, 2008 1 次提交
  9. 25 7月, 2008 1 次提交
  11. 13 7月, 2008 1 次提交
  13. 11 7月, 2008 1 次提交
  15. 12 6月, 2008 1 次提交
  17. 14 5月, 2008 1 次提交
  19. 01 5月, 2008 1 次提交
    • 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
  21. 21 4月, 2008 1 次提交
  23. 17 4月, 2008 2 次提交
  25. 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
  27. 13 10月, 2007 2 次提交
  29. 11 10月, 2007 1 次提交
  31. 03 5月, 2007 1 次提交
  33. 02 12月, 2006 1 次提交
  35. 03 11月, 2006 1 次提交
  37. 28 6月, 2006 1 次提交
  39. 26 6月, 2006 1 次提交
  41. 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
  43. 24 11月, 2005 1 次提交
  45. 09 9月, 2005 1 次提交
  47. 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
  49. 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
  51. 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