27 Sep, 2006

1 commit

  • 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

    Satoru Takeuchi
     

28 Jun, 2006

1 commit


22 Jun, 2006

1 commit

  • 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

    Kimball Murray
     

24 Oct, 2005

1 commit

  • 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

    Linus Torvalds
     

10 Sep, 2005

1 commit

  • 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

    Dominik Brodowski
     

31 Aug, 2005

1 commit

  • 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

    Ivan Kokshaysky
     

27 Aug, 2005

1 commit


30 Jul, 2005

1 commit

  • 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

    Ivan Kokshaysky
     

07 Jul, 2005

1 commit

  • 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

    Ivan Kokshaysky
     

02 Jul, 2005

1 commit

  • - 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
    Signed-off-by: Greg Kroah-Hartman

    Ivan Kokshaysky
     

28 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds