linux-toradex.git/drivers/pci/setup-bus.c, branch v2.6.19.2

[PATCH] fix "PCI: assign ioapic resource at hotplug"

2006-10-04T14:55:14+00:00

Roland Dreier wrote:
> The change "PCI: assign ioapic resource at hotplug" (commit
> 23186279658cea6d42a050400d3e79c56cb459b4 in Linus's tree) makes
> networking stop working on my system (SuperMicro H8QC8 with four
> dual-core Opteron 885 CPUs).  In particular, the on-board NIC stops
> working, probably because it gets assigned the wrong IRQ (225 in the
> non-working case, 217 in the working case)
>
> With that patch applied, e1000 doesn't work.  Reverting just that
> patch (shown below) from Linus's latest tree fixes things for me.
>

The cause of this problem might be an wrong assumption that the 'start'
member of resource structure for ioapic device has non-zero value if the
resources are assigned by firmware.  The 'start' member of ioapic device
seems not to be set even though the resources were actually assigned to
ioapic devices by firmware.

Cc: Kenji Kaneshige 
Cc: MUNEDA Takahiro 
Cc: Satoru Takeuchi 
Cc: Kristen Carlson Accardi 
Cc: Greg Kroah-Hartman 
Cc: Roland Dreier 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

PCI: assign ioapic resource at hotplug

2006-09-27T00:43:54+00:00

We need to assign resources to ioapics being hot-added. This patch
changes pbus_assign_resources_sorted() to assign resources if the
ioapic has no assigned resources.

Signed-off-by: Kenji Kaneshige 
Signed-off-by: MUNEDA Takahiro 
Signed-off-by: Satoru Takeuchi 
Signed-off-by: Kristen Carlson Accardi 
Signed-off-by: Greg Kroah-Hartman

[PATCH] 64bit resource: fix up printks for resources in pci core and hotplug drivers

2006-06-27T16:23:58+00:00

This is needed if we wish to change the size of the resource structures.

Based on an original patch from Vivek Goyal 

Cc: Vivek Goyal 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

[PATCH] PCI: don't move ioapics below PCI bridge

2006-06-21T19:00:00+00:00

A recent Stratus x86_64 platform uses a system ioapic that is a PCI device
located below a PCI bridge.  Other platforms like this may exist.

This patch fixes a problem wherein the kernel's PCI setup code moves
the ioapic to an address other than that assigned by the BIOS.  It simply
adds another exclusion (which already includes classless devices and host
bridges) to the function pbus_assign_resources_sorted so that it will not
move the ioapic.

If the ioapic is moved, the fixmap mapping to it is broken, so the OS should
leave it alone.

From: Kimball Murray 
Signed-off-by: Greg Kroah-Hartman

cardbus: limit IO windows to 256 bytes

2005-10-23T23:31:16+00:00

That's what we've always historically done, and bigger windows seem to
confuse some cardbus bridges. Or something.

Alan reports that this makes the ThinkPad 600x series work properly
again: the 4kB IO window for some reason made IDE DMA not work, which
makes IDE painfully slow even if it works after DMA timeouts.

Signed-off-by: Linus Torvalds

[PATCH] yenta: share code with PCI core

2005-09-09T20:57:47+00:00

Share code between setup-bus.c and yenta_socket.c: use the write-out code of
resources to the bridge also in yenta_socket.c, as it provides useful debug
output.  In addition, it fixes the bug that the CPU-centric resource view
might need to be transferred to the PCI-centric view: setup-bus.c does that,
while yenta-socket.c did not.

Signed-off-by: Dominik Brodowski 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] x86: pci_assign_unassigned_resources() update

2005-08-30T18:14:48+00:00

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  (who had problems with
the 4kB CardBus IO size previously).

Signed-off-by: Linus Torvalds

Only pre-allocate 256 bytes of cardbio IO range

2005-08-26T17:40:10+00:00

It may seem small, but most cards need much less, if any, and this not
only makes the code adhere to the comment, it seems to fix a boot-time
lockup on a ThinkPad 380XD laptop reported by Tero Roponen 

Signed-off-by: Linus Torvalds

[PATCH] PCI: remove PCI_BRIDGE_CTL_VGA handling from setup-bus.c

2005-07-29T20:12:51+00:00

The setup-bus code doesn't work correctly for configurations
with more than one display adapter in the same PCI domain.
This stuff actually is a leftover of an early 2.4 PCI setup code
and apparently it stopped working after some "bridge_ctl" changes.
So the best thing we can do is just to remove it and rely on the fact
that any firmware *has* to configure VGA port forwarding for the boot
display device properly.

But then we need to ensure that the bus->bridge_ctl will always
contain valid information collected at the probe time, therefore
the following change in pci_scan_bridge() is needed.

Signed-off-by: Ivan Kokshaysky 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds

[PATCH] yet another fix for setup-bus.c/x86 merge

2005-07-06T23:12:58+00:00

There is a slight disagreement between setup-bus.c code and traditional
x86 PCI setup wrt which recourses are invalid vs resources that are free
for further allocations.

In particular, in the setup-bus.c, if we failed to allocate some resource,
we nullify "start" and "flags" fields, but *not* the "end" one.

But x86 pcibios_enable_resources() does the following check:

	if (!r->start && r->end) {
		printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
		return -EINVAL;

which means that the device owning the offending resource cannot be
enabled.

In particular, this breaks cardbus behind the normal decode p2p bridge -
the cardbus code from setup-bus.c requests rather large IO and MEM
windows, and if it fails, the socket is completely unavailable.  Which
is wrong, as the yenta code is capable to allocate smaller windows.

Signed-off-by: Ivan Kokshaysky 
Signed-off-by: Linus Torvalds