- 28 Jun, 2005 40 commits
-
-
-
Greg Kroah-Hartman authored
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:Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
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: -
Greg Kroah-Hartman authored
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: -
Greg Kroah-Hartman authored
Now we can change the pci core to always set this pointer, as pci drivers should use it, not the driver core callback. Signed-off-by: -
Keith Moore authored
drivers/pci/hotplug/cpqphp_core.c calls cpqphp_event_start_thread() in one_time_init(), which is called whenever the hardware is probed. Unfortunately, cpqphp_event_stop_thread() is *always* called when the module is unloaded. If the hardware is never probed, then cpqphp_event_stop_thread() tries to manipulate a couple of uninitialized mutexes. Signed-off-by:
Keith Moore <keithmo@exmsft.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Mostly just cleans up the irq handling logic to be smaller and a bit more descriptive as to what it really does. Signed-off-by: -
Andrew Morton authored
With CONFIG_PCI=n: In file included from include/linux/pci.h:917, from lib/iomap.c:6: include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want. include/asm/pci.h: In function `pci_dma_burst_advice': include/asm/pci.h:106: dereferencing pointer to incomplete type include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function) include/asm/pci.h:106: (Each undeclared identifier is reported only once include/asm/pci.h:106: for each function it appears in.) make[1]: *** [lib/iomap.o] Error 1 Signed-off-by:Andrew Morton <akpm@osdl.org> Signed-off-by:
-
David S. Miller authored
After seeing, at best, "guesses" as to the following kind of information in several drivers, I decided that we really need a way for platforms to specifically give advice in this area for what works best with their PCI controller implementation. Basically, this new interface gives DMA bursting advice on PCI. There are three forms of the advice: 1) Burst as much as possible, it is not necessary to end bursts on some particular boundary for best performance. 2) Burst on some byte count multiple. A DMA burst to some multiple of number of bytes may be done, but it is important to end the burst on an exact multiple for best performance. The best example of this I am aware of are the PPC64 PCI controllers, where if you end a burst mid-cacheline then chip has to refetch the data and the IOMMU translations which hurts performance a lot. 3) Burst on a single byte count multiple. Bursts shall end exactly on the next multiple boundary for best performance. Sparc64 and Alpha's PCI controllers operate this way. They disconnect any device which tries to burst across a cacheline boundary. Actually, newer sparc64 PCI controllers do not have this behavior. That is why the "pdev" is passed into the interface, so I can add code later to check which PCI controller the system is using and give advice accordingly. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Michael Ellerman authored
This is an updated version of Ben's fix-pci-mmap-on-ppc-and-ppc64.patch which is in 2.6.12-rc4-mm1. It fixes the patch to work on PPC iSeries, removes some debug printks at Ben's request, and incorporates your fix-pci-mmap-on-ppc-and-ppc64-fix.patch also. Originally from Benjamin Herrenschmidt <benh@kernel.crashing.org> This patch was discussed at length on linux-pci and so far, the last iteration of it didn't raise any comment. It's effect is a nop on architecture that don't define the new pci_resource_to_user() callback anyway. It allows architecture like ppc who put weird things inside of PCI resource structures to convert to some different value for user visible ones. It also fixes mmap'ing of IO space on those archs. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
Kenji Kaneshige authored
This patch adds PCI based I/O xAPIC hot-add support to ACPIPHP driver. When PCI root bridge is hot-added, all PCI based I/O xAPICs under the root bridge are hot-added by this patch. Hot-remove support is TBD. Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Kenji Kaneshige authored
This is an ia64 implementation of acpi_register_ioapic() and acpi_unregister_ioapic() interfaces. Signed-off-by:
-
Kenji Kaneshige authored
This patch adds the following new interfaces for I/O xAPIC hotplug. The implementation of these interfaces depends on each architecture. o int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base); This new interface is to add a new I/O xAPIC specified by phys_addr and gsi_base pair. phys_addr is the physical address to which the I/O xAPIC is mapped and gsi_base is global system interrupt base of the I/O xAPIC. acpi_register_ioapic returns 0 on success, or negative value on error. o int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base); This new interface is to remove a I/O xAPIC specified by gsi_base. acpi_unregister_ioapic returns 0 on success, or negative value on error. Signed-off-by: -
Rajesh Shah authored
Current acpiphp code does not distinguish between the physical presence and power state of a device/slot. That is, if a device has to be disabled, it also tries to physically ejects the device. This patch decouples power state from physical presence. You can now echo to the corresponding sysfs power control file to repeatedly enable and disable a device without having to physically re-insert it. Signed-off-by:
Rajesh Shah <rajesh.shah@intel.com> Signed-off-by:
-
Rajesh Shah authored
acpiphp changes to support acpi based root bridge hot-add. Signed-off-by:
-
Rajesh Shah authored
Earlier I reported that Matthew's acpiphp rewrite had problem in powering down slot on my i386 system. The following patch is needed to get the acpiphp rewrite properly powering down the slot. Signed-off-by:
Dely Sy <dely.l.sy@intel.com> Signed-off-by:
-
Rajesh Shah authored
A root bridge may not have directly attached hotpluggable slots under it. Instead, it may have p2p bridges with slots under it. In this case, we need to clean up the p2p bridges and slots properly too. Patch below applies on top of the original patch, and fixes this problem. Without this, acpiphp leaves behind notify handlers on module unload, and subsequent module load attempts don't work properly too. Patch was tested on an ia64 Tiger4 box. Signed-off-by:
-
Rajesh Shah authored
This patch converts acpiphp to use the generic PCI resource assignment code. It's quite large, but most of it is deleting the acpiphp_pci and acpiphp_res files. It's tested on an hp Integrity rx8620 (which won't work without this patch). Testers with other hardware welcomed. Signed-off-by:
Matthew Wilcox <matthew@wil.cx> Signed-off-by:
-
Rajesh Shah authored
Export an acpi interface to get PCI domain/bus/devfn information from the corresponding namespace handle. Used by acpiphp code to transpate the device handle of the hot-plugged root bridge to the corresponding pci location information. Signed-off-by:
-
Rajesh Shah authored
Create new interfaces to recursively add an acpi namespace object to the acpi device list, and recursively start the namespace object. This is needed for ACPI based hotplug of a root bridge hierarchy where the add operation must be performed first and the start operation must be performed separately after the hot-plugged devices have been properly configured. Signed-off-by:
-
Rajesh Shah authored
Read bridge io/mem/pfmem ranges when fixing up the bus so that bus resources are tracked. This is required to properly support pci end device and bridge hotplug. Signed-off-by:
-
Rajesh Shah authored
When hot-plugging an I/O hierarchy that contains many bridges and leaf devices, it's possible that there are not enough resources to start all the device present. If we fail to assign a resource, clear the corresponding value in the pci_dev structure, so other code can take corrective action. Signed-off-by:
-
Rajesh Shah authored
When a root bridge hierarchy is hot-plugged, resource requirements for the new devices may be greater than what the root bridge is decoding. In this case, we want to remove devices that did not get needed resources. These devices have been scanned into bus specific lists but not yet added to the global device list. Make sure the pci remove functions can handle this case. Signed-off-by:
-
Rajesh Shah authored
When a pci child bus is created, add it to the parent's children list immediately rather than waiting till pci_bus_add_devices(). For hot-plug bridges/devices, pci_bus_add_devices() may be called much later, after they have been properly configured. In the meantime, this allows us to use the normal pci bus search functions for the hot-plug bridges/buses. Signed-off-by:
-
Rajesh Shah authored
With root bridge and pci bridge hot-plug, new buses and devices can be added or removed at run time. Protect the pci bus and device lists with the pci lock when doing so. Signed-off-by:
-
Rajesh Shah authored
When hot-plugging a root bridge, as we try to assign bus numbers we may find that the hotplugged hieratchy has more PCI to PCI bridges (i.e. bus requirements) than available. Make sure we don't step over an existing bus when that happens. Signed-off-by:
-
Rajesh Shah authored
PCI scan code calls the arch specific pcibios_fixup_bus() each time it scans a new bridge. For root bridge hot-plug, the bridge and it's attached devices may not have been configured properly yet, so it's not safe to claim those resources at this time. This code goes away when we clean up the way pci resources are claimed (in pci_enable_device()), so this is only a stopgap fix. Signed-off-by:
-
Rajesh Shah authored
When checking if a PCI to PCI bridge should be enabled to decode memory and/or IO resources, we need to look at all device resources not just the first 6. This is needed to allow PCI bridges to pass down memory and IO accesses to child devices even when the bridge itself does not consume resources in its PCI BARs. Signed-off-by:
-
Rajesh Shah authored
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:
-
Amit Gud authored
Replace pci_find_device() with more safer pci_get_device(). Signed-off-by:
Amit Gud <gud@eth.net> Signed-off-by:
-
Amit Gud authored
Replace pci_find_device() with more safer pci_get_device(). Signed-off-by:
-
jayalk@intworks.biz authored
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:
Jaya Kumar <jayalk@intworks.biz> Signed-off-by:
-
Andrew Morton authored
drivers/block/cfq-iosched.c: In function 'cfq_put_queue': drivers/block/cfq-iosched.c:303: sorry, unimplemented: inlining failed in call to 'cfq_pending_requests': function body not available drivers/block/cfq-iosched.c:1080: sorry, unimplemented: called from here drivers/block/cfq-iosched.c: In function '__cfq_may_queue': drivers/block/cfq-iosched.c:1955: warning: the address of 'cfq_cfqq_must_alloc_slice', will always evaluate as 'true' make[1]: *** [drivers/block/cfq-iosched.o] Error 1 make: *** [drivers/block/cfq-iosched.o] Error 2 Cc: Jeff Garzik <jgarzik@pobox.com> Cc: Jens Axboe <axboe@suse.de> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
-
Dominik Brodowski authored
Don't auto-configure yenta sockets for PCMCIA devices if it is connected to the root PCI bus on the x86 or x86_64 architectures. Previously, this was handled by the "ioport_resource"/"iomem_resource" check a few lines below, but with the new ACPI-based resource handling this doesn't catch all cases any longer. pci-yenta-cardbus-fix.patch and this patch should solve the initialization time trouble. However, the ACPI-based PCI resource handling is badly broken, IMHO: - many resources of devices don't show up in the resource trees ( /proc/iomem and /proc/ioports) any longer. This means that PCMCIA, but also possibly other subsystems (ISA, PnP, ...) do not know which resources it cannot use. - verify_root_windows() should fail if there are no iomem _or_ ioport resources, not only if there are no iomem _and_ ioport resources. Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Dominik Brodowski authored
Provide a "modalias" entry in sysfs for PCMCIA devices. Signed-off-by:
-
Dominik Brodowski authored
The PCMCIA card services layer is never setting the i/o map attributes when SS_CAP_STATIC_MAP is specified. Net result, sockets' set_io_map() calls always see requests with most flags clear, meaning 8 bit access. For hardware that always autosizes, that won't matter; and all current STATIC_MAP drivers ignore those attributes. A new driver (for at91rm9200) suffers badly from this, since this forces everything into 8 bit mode and that breaks both (a) cards requiring 16 bit access, and (b) ide-cs; but of course 8-bit cards work OK (as does accessing card attributes). So this patch arranges to pass the attributes down, matching the behavior for non-static mappings (using the first/only I/O window). Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.de> Signed-off-by:
-
Dominik Brodowski authored
register_chrdev() can return errors (negative) other then -EBUSY, so check for any negative error code. Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Jar authored
Fix example hash generator in Documentation. Signed-off-by:
-
Dominik Brodowski authored
- properly bail out in set_cis_map if call to socket driver's set_mem_map failed - don't abort do_mem_probe cycle if one entry failed (!CONFIG_PCMCIA_PROBE) - don't do iomem probing in chunks larger than 0x800000 (1 << 23) as yenta_socket and vrc4173_cardu.c fail to set_mem_map for windows equal to or larger than (1 << 24). Signed-off-by:
-
