Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 05 11月, 2009 2 次提交
  3. 28 9月, 2009 1 次提交
  5. 11 7月, 2009 1 次提交
    • Y
      x86/pci: insert ioapic resource before assigning unassigned resources · 857fdc53
      由 Yinghai Lu 提交于 
      Stephen reported that his DL585 G2 needed noapic after 2.6.22 (?)

Dann bisected it down to:
  commit 30a18d6c
  Date:   Tue Feb 19 03:21:20 2008 -0800

      x86: multi pci root bus with different io resource range, on
      64-bit

It turns out that:
  1. that AMD-based systems have two HT chains.
  2. BIOS doesn't allocate resources for BAR 6 of devices under 8132 etc
  3. that multi-peer-root patch will try to split root resources to peer
     root resources according to PCI conf of NB
  4. PCI core assigns unassigned resources, but they overlap with BARs
     that are used by ioapic addr of io4 and 8132.

The reason: at that point ioapic address are not inserted yet.  Solution
is to insert ioapic resources into the tree a bit earlier.
Reported-by: NStephen Frost <sfrost@snowman.net>
Reported-and-Tested-by: Ndann frazier <dannf@hp.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: stable@kernel.org
Signed-off-by: NJesse Barnes <jbarnes@jbarnes-g45.(none)>
      857fdc53
  7. 18 6月, 2009 1 次提交
  9. 23 4月, 2009 1 次提交
  11. 04 4月, 2009 1 次提交
    • S
      x86, PAT: Remove duplicate memtype reserve in pci mmap · 5a3ae276
      由 Suresh Siddha 提交于 
      pci mmap code was doing memtype reserve for a while now. Recently we
added memtype tracking in remap_pfn_range, and pci code indirectly calls
remap_pfn_range. So, we don't need seperate tracking in pci code
anymore. Which means a patch that removes ~50 lines of code :-).

Also, recently we found out that the pci tracking is not working as we expect
it to work in some cases. Specifically, userlevel X mmap of pci, with some
recent version of X, is having a problem with vm_page_prot getting reset.
The pci tracking uses vm_page_prot to pass on the protection type from parent
to child during fork.
a) Parent does a pci mmap
b) We look at PAT and get either UC_MINUS or WC mapping for parent
c) Store that mapping type in vma vm_page_prot for future use
d) This thread does a fork
e) Fork results in mmap_ops ->open for the child process
f) We get the vm_page_prot from vma and reserve that type for the child process

But, between c) and e) above, the vma vm_page_prot is getting reset to zero.
This results in PAT reserve failing at the time of fork as in here.
http://marc.info/?l=linux-kernel&m=123858163103240&w=2

This cleanup makes the above problem go away as we do not depend on
vm_page_prot in our PAT code anymore.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5a3ae276
  13. 24 3月, 2009 1 次提交
  15. 14 1月, 2009 1 次提交
  17. 08 1月, 2009 1 次提交
  19. 30 12月, 2008 1 次提交
  21. 04 9月, 2008 2 次提交
  23. 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
  25. 30 8月, 2008 1 次提交
  27. 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
  29. 29 7月, 2008 1 次提交
  31. 25 7月, 2008 1 次提交
  33. 13 7月, 2008 1 次提交
  35. 11 7月, 2008 1 次提交
  37. 12 6月, 2008 1 次提交
  39. 14 5月, 2008 1 次提交
  41. 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
  43. 21 4月, 2008 1 次提交
  45. 17 4月, 2008 2 次提交
  47. 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
  49. 13 10月, 2007 2 次提交
  51. 11 10月, 2007 1 次提交
  53. 03 5月, 2007 1 次提交
  55. 02 12月, 2006 1 次提交
  57. 03 11月, 2006 1 次提交
  59. 28 6月, 2006 1 次提交
  61. 26 6月, 2006 1 次提交
  63. 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
  65. 24 11月, 2005 1 次提交
  67. 09 9月, 2005 1 次提交
  69. 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
  71. 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