Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 4月, 2006 2 次提交
  3. 24 3月, 2006 2 次提交
    • B
      [PATCH] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix · 8c4b2cf9
      由 Bernhard Kaindl 提交于 
      "In some cases, especially on modern laptops with a lot of PCI and cardbus
bridges, we're unable to assign correct secondary/subordinate bus numbers
to all cardbus bridges due to BIOS limitations unless we are using
"pci=assign-busses" boot option." -- Ivan Kokshaysky (from a patch comment)

Without it, Cardbus cards inserted are never seen by PCI because the parent
PCI-PCI Bridge of the Cardbus bridge will not pass and translate Type 1 PCI
configuration cycles correctly and the system will fail to find and
initialise the PCI devices in the system.

Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering:
http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html

The reason for this is that:
 ``All PCI busses located behind a PCI-PCI bridge must reside between the
secondary bus number and the subordinate bus number (inclusive).''

"pci=assign-busses" makes pcibios_assign_all_busses return 1 and this
turns on PCI renumbering during PCI probing.

Alan suggested to use DMI automatically set assign-busses on problem systems.

The only question for me was where to put it.  I put it directly before
scanning PCI bus into pcibios_scan_root() because it's called from legacy,
acpi and numa and so it can be one place for all systems and configurations
which may need it.

AMD64 Laptops are also affected and fixed by assign-busses, and the code is
also incuded from arch/x86_64/pci/ that place will also work for x86_64
kernels, I only ifdef'-ed the x86-only Laptop in this example.

Affected and known or assumed to be fixed with it are (found by googling):

* ASUS Z71V and L3s
* Samsung X20
* Compaq R3140us and all Compaq R3000 series laptops with TI1620 Controller,
  also Compaq R4000 series (from a kernel.org bugreport)
* HP zv5000z (AMD64 3700+, known that fixup_parent_subordinate_busnr fixes it)
* HP zv5200z
* IBM ThinkPad 240
* An IBM ThinkPad (1.8 GHz Pentium M) debugged by Pavel Machek
  gives the correspondig message which detects the possible problem.
* MSI S260 / Medion SIM 2100 MD 95600

The patch also expands the "try pci=assign-busses" warning so testers will
help us to update the DMI table.

Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8c4b2cf9
    • A
      [PATCH] PCI: Give PCI config access initialization a defined ordering · 92c05fc1
      由 Andi Kleen 提交于 
      I moved it to a separate function which is safer.

This avoids problems with the linker reordering them and the
less useful PCI config space access methods taking priority
over the better ones.

Fixes some problems with broken MMCONFIG

Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      92c05fc1
  5. 01 2月, 2006 2 次提交
  7. 15 1月, 2006 1 次提交
    • D
      [PATCH] gx1fb: (try to) play nicer with various BIOSes · a80da738
      由 David Vrabel 提交于 
      Seems that the CS5530A chip used in Geode GX1 systems has some crazy feature
that causes SMI traps when accessing the PCI configuration space of the video
device.  Various GX1 BIOSes seem to use this 'feature' to hide the real BARs
of the device.  This patch disables these traps (in an early PCI fixup) so
that Linux sees the real, physical BARs and not the virtual ones provided by
the BIOS.

This should allow the GX1 framebuffer driver to work on more systems that have
different BIOSes as the driver no longer guesses at what the virtual BARs
mean.

I'm not entirely sure it the correct solution as I can neither test regular
VGA console nor the X's 'cyrix' video driver so there might be some breakage
there -- probably best to get some more testers before applying it.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a80da738
  9. 10 1月, 2006 3 次提交
  11. 07 1月, 2006 1 次提交
  13. 21 12月, 2005 1 次提交
  15. 17 12月, 2005 1 次提交
  17. 16 12月, 2005 1 次提交
  19. 13 12月, 2005 2 次提交
  21. 24 11月, 2005 3 次提交
  23. 11 11月, 2005 1 次提交
    • J
      [PATCH] PCI: fix for Toshiba ohci1394 quirk · 6e6ece5d
      由 Jesse Barnes 提交于 
      After much testing and agony, I've discovered that my previous ohci1394
quirk for Toshiba laptops is not 100% reliable.  It apparently fails to
do the interrupt line change either correctly or in time, since in about
2 out of 5 boots, the kernel's irqdebug code will *still* disable irq 11
when the ohci1394 driver is loaded (at pci_enable_device time I think).

This patch switches things around a little in the workaround.  First, it
removes the mdelay.  I didn't see a need for it and my testing has shown
that it's not necessary for the quirk to work.

Secondly, instead of trying to change the interrupt line to what ACPI
tells us it should be, this patch makes the quirk use the value in the
PCI_INTERRUPT_LINE register.  On this laptop at least, that seems to be
the right thing to do, though additional testing on other laptops and/or
with actual firewire devices would be appreciated.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6e6ece5d
  25. 02 11月, 2005 1 次提交
  27. 31 10月, 2005 1 次提交
  29. 29 10月, 2005 1 次提交
    • J
      [PATCH] PCI fixup for Toshiba laptops and ohci1394 · f8977d0a
      由 Jesse Barnes 提交于 
      This is a fix for a bug I see on my Toshiba laptop, where the ohci1394
controller gets initialized improperly.  The patch adds two PCI fixups
to arch/i386/pci/fixup.c, one that happens early on to cache the value
of the PCI_CACHE_LINE_SIZE config register, and another that later
restores the value, along with a valid IRQ number and some BAR values.
I've tested it on my laptop, and it prevents me from running into what I
consider to be a major bug: IRQ 11 is disabled by the IRQ debug code,
causing my wireless to break.

Thanks to Rob for the original patch to ohci1394.c and Stefan for lots
of proofreading (and a last minute bug caught in review!) and additional
information collection.  I think the DMI system list is correct, but we
may need to add some more PCI IDs to the PCI_FIXUP macros over time.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f8977d0a
  31. 01 10月, 2005 1 次提交
  33. 27 9月, 2005 1 次提交
  35. 13 9月, 2005 2 次提交
  37. 09 9月, 2005 1 次提交
  39. 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
  41. 26 8月, 2005 1 次提交
  43. 08 8月, 2005 1 次提交
  45. 30 7月, 2005 1 次提交
  47. 28 7月, 2005 1 次提交
  49. 12 7月, 2005 1 次提交
  51. 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
  53. 28 6月, 2005 4 次提交
    • G
      [PATCH] PCI: use the MCFG table to properly access pci devices (i386) · d57e26ce
      由 Greg Kroah-Hartman 提交于 
      Now that we have access to the whole MCFG table, let's properly use it
for all pci device accesses (as that's what it is there for, some boxes
don't put all the busses into one entry.)

If, for some reason, the table is incorrect, we fallback to the "old
style" of mmconfig accesses, namely, we just assume the first entry in
the table is the one for us, and blindly use it.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d57e26ce
    • G
      [PATCH] PCI: add proper MCFG table parsing to ACPI core. · 54549391
      由 Greg Kroah-Hartman 提交于 
      This patch is the first step in properly handling the MCFG PCI table.
It defines the structures properly, and saves off the table so that the
pci mmconfig code can access it.  It moves the parsing of the table a
little later in the boot process, but still before the information is
needed.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      54549391
    • R
      [PATCH] acpi bridge hotadd: ACPI based root bridge hot-add · c431ada4
      由 Rajesh Shah 提交于 
      When you hot-plug a (root) bridge hierarchy, it may have p2p bridges and
devices attached to it that have not been configured by firmware.  In this
case, we need to configure the devices before starting them.  This patch
separates device start from device scan so that we can introduce the
configuration step in the middle.

I kept the existing semantics for pci_scan_bus() since there are a huge number
of callers to that function.

Also, I have no way of testing the changes I made to the parisc files, so this
needs review by those folks.  Sorry for the massive cross-post, this touches
files in many different places.
Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c431ada4
    • J
      [PATCH] PCI Allow OutOfRange PIRQ table address · 120bb424
      由 jayalk@intworks.biz 提交于 
      I updated this to remove unnecessary variable initialization, make
check_routing be inline only and not __init, switch to strtoul, and
formatting fixes as per Randy Dunlap's recommendations.

I updated this to change pirq_table_addr to a long, and to add a warning
msg if the PIRQ table wasn't found at the specified address, as per thread
with Matthew Wilcox.

In our hardware situation, the BIOS is unable to store or generate it's PIRQ
table in the F0000h-100000h standard range. This patch adds a pci kernel
parameter, pirqaddr to allow the bootloader (or BIOS based loader) to inform
the kernel where the PIRQ table got stored. A beneficial side-effect is that,
if one's BIOS uses a static address each time for it's PIRQ table, then
pirqaddr can be used to avoid the $pirq search through that address block each
time at boot for normal PIRQ BIOSes.
Signed-off-by: NJaya Kumar <jayalk@intworks.biz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      120bb424
  55. 24 6月, 2005 1 次提交