- 09 Sep, 2009 39 commits
-
-
Kenji Kaneshige authored
Fix typo in PCI-E link speed. Reviewed-by:
Matthew Wilcox <matthew@wil.cx> Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Kenji Kaneshige authored
The L0s state can be managed separately for each direction (upstream direction and downstream direction) of the link. But in the current implementation, those are mixed up. With this patch, L0s for each direction are managed separately. To maintain three states (upstream direction L0s, downstream L0s and L1), 'aspm_support', 'aspm_enabled', 'aspm_capable', 'aspm_disable' and 'aspm_default' fields in struct pcie_link_state are changed to 3-bit from 2-bit. The 'latency' field is separated to two 'latency_up' and 'latency_dw' fields to maintain exit latencies for each direction of the link. For L0, 'latency_up.l0' and 'latency_dw.l0' are used to configure upstream direction L0s and downstream direction L0s respectively. For L1, larger value of 'latency_up.l1' and 'latency_dw.l1' is considered as L1 exit latency. Acked-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Kenji Kaneshige authored
In the current implementation, ASPM L0s/L1 is disabled for all links in the hierarchy if one of the link doesn't meet latency requirement. But we can partially enable ASPM L0s/L1 on sub-tree in the hierarchy. This patch allows partial L0s/L1 enablement in the hierarchy. And it also reduce the calculation cost of ASPM configuration very much. In the previous implementation, all links were enabled with the same state. With this patch, enabled state for each link is determined simply as follows (the 'requested' is from policy_to_aspm_state()). enabled = requested & (link->aspm_capable & link->aspm_disable) Acked-by: -
Kenji Kaneshige authored
Introduce 'aspm_capable' field to maintain the capable ASPM setting of the link. By the 'aspm_capable', we don't need to recheck latency every time ASPM policy is changed. Each bit in 'aspm_capable' is associated to ASPM state (L0S/L1). The bit is set if the associated ASPM state is supported by the link and it satisfies the latency requirement (i.e. exit latency < endpoint acceptable latency). The 'aspm_capable' is updated when - an endpoint device is added (boot time or hot-plug time) - an endpoint device is removed (hot-unplug time) - PCI power state is changed. Acked-by:
-
Kenji Kaneshige authored
Introduce 'aspm_disable' flag to manage disabled ASPM state more robust way. Acked-by:
-
Kenji Kaneshige authored
Fix possible NULL dereference in pcie_aspm_exit_link_state(). This patch also cleanup some code. Acked-by:
-
Kenji Kaneshige authored
Remove the following check in __pcie_aspm_config_link() because it nerver be true. Acked-by:
-
Kenji Kaneshige authored
We must not clear bits in 'aspm_enabled' using 'aspm_support', or 'aspm_enabled' and 'aspm_default' might be different from the actual state. In addtion, 'aspm_default' should be intialized even if 'aspm_support' is 0. Acked-by:
-
Alexander Duyck authored
This patch adds the most recent additions to the list of 82576 device IDs to the list of devices needing the SR-IOV quirk. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Tiago Vignatti authored
Document the new VGA arbiter. Signed-off-by:
Tiago Vignatti <tiago.vignatti@nokia.com> Signed-off-by:
-
Dave Airlie authored
Fix some warnings reported in linux-next + also cleanup some comment errors noticed by Pekka Paalanen. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Mike Mason authored
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch makes changes to EEH to utilize the new bit field. Signed-off-by:
Mike Mason <mmlnx@us.ibm.com> Signed-off-by:
Richard Lary <rlary@us.ibm.com> Signed-off-by:
-
Mike Mason authored
The attached patch updates the Documentation/PCI/pci-error-recovery.txt file with changes related to this new bit field, as well a few unrelated updates. Signed-off-by:
Linas Vepstas <linasvepstas@gmail.com> Signed-off-by:
-
Mike Mason authored
This is the first of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery. By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that indicates whether the device requires a fundamental reset during recovery. These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Signed-off-by:
-
Benjamin Herrenschmidt authored
Background: Graphic devices are accessed through ranges in I/O or memory space. While most modern devices allow relocation of such ranges, some "Legacy" VGA devices implemented on PCI will typically have the same "hard-decoded" addresses as they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994 Standard for Boot (Initialization Configuration) Firmware Revision 2.1" Section 7, Legacy Devices. The Resource Access Control (RAC) module inside the X server currently does the task of arbitration when more than one legacy device co-exists on the same machine. But the problem happens when these devices are trying to be accessed by different userspace clients (e.g. two server in parallel). Their address assignments conflict. Therefore an arbitration scheme _outside_ of the X server is needed to control the sharing of these resources. This document introduces the operation of the VGA arbiter implemented for Linux kernel. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Hidetoshi Seto authored
Cleanups (nearly based on checkpatch). Before: total: 11 errors, 2 warnings, 0 checks, 842 lines checked After: total: 0 errors, 0 warnings, 0 checks, 842 lines checked v2: fix it's/its mistakes in comment Reviewed-by:
Matthew Wilcox <willy@linux.intel.com> Signed-off-by:
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by:
-
Hidetoshi Seto authored
Cleanup based on the prototype from Matthew Milcox. Reviewed-by:
-
Hidetoshi Seto authored
Cleanup based on the prototype from Matthew Milcox. Reviewed-by:
-
Hidetoshi Seto authored
Cleanup based on the prototype from Matthew Milcox. Reviewed-by:
-
Hidetoshi Seto authored
Move it from the middle of the function to the end. Reviewed-by:
-
Hidetoshi Seto authored
Unify msi_free_irqs() and msix_free_all_irqs(), and rename it to a common void function free_msi_irqs(). And relocate the common function to where the prototype is located now. Reviewed-by:
-
Hidetoshi Seto authored
use list_first_entry() instead of list_entry(). Reviewed-by:
-
Hidetoshi Seto authored
The msi_list never have MSI-X's msi_desc while MSI is enabled, and also it never have MSI's msi_desc while MSI-X is enabled. This patch remove check for MSI-X entry from the pci_disable_msi(), referring that pci_disable_msix() does not have any check for MSI entry. Reviewed-by:
-
Alex Williamson authored
This avoids a "Malformed early option 'iommu'" on boot when trying to use pass-through mode. Signed-off-by:
Alex Williamson <alex.williamson@hp.com> Signed-off-by:
-
Dave Jones authored
IDs should generally only be added to pci_ids.h when they're shared across several files in the tree. IDs that are just used by a single driver should be defined in the driver instead. Perhaps documenting this is a good idea to prevent things being moved there, as it still seems to be happening judging from the git log. (based on discussion w/gregkh and others). Acked-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Yinghai Lu authored
We already print it out for pci bridges, so also print it out for pci devices. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Tejun Heo authored
http://bugzilla.kernel.org/show_bug.cgi?id=12542 reports that with the quirk not applied on resume, msi stops working after resuming and mcp78s ahci fails due to IRQ mis-delivery. Apply it on resume too. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Peer Chen <pchen@nvidia.com> Cc: Tj <linux@tjworld.net> Reported-by:
Nicolas Derive <kalon33@ubuntu.com> Cc: Greg KH <greg@kroah.com> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andi Kleen authored
Shut off the long standing linux/drivers/pci/search.c:144: warning: 'pci_find_device' is deprecated (declared at linux/drivers/pci/search.c:136) linux/drivers/pci/search.c:144: warning: 'pci_find_device' is deprecated (declared at linux/drivers/pci/search.c:136) warnings that appear on every build when CONFIG_PCI_LEGACY is enabled. gcc warns for the use in EXPORT_SYMBOL I moved these to a separate file and disabled the warning in the Makefile for that file. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Jean Delvare authored
One more form factor for Compaq Evo D510, which needs the same quirk as the other form factors. Apparently there's no hardware monitoring chip on that one, but SPD EEPROMs, so it's still worth unhiding the SMBus. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
Nuzhna Pomoshch <nuzhna_pomoshch@yahoo.com> Signed-off-by:
-
Michael S. Tsirkin authored
Some devices allow an individual function to be reset without affecting other functions in the same device: that's what pci_reset_function does. For devices that have this support, expose reset attribite in sysfs. This is useful e.g. for virtualization, where a qemu userspace process wants to reset the device when the guest is reset, to emulate machine reboot as closely as possible. Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Alex Chiang authored
We cannot simply call acpi_get_pci_dev() on any random ACPI handle and hope that it works, because a PCI root bridge may not have an associated struct pci_dev. This is allowed per the PCI specification, and is referred to as a non-materialized bridge. So, depending on the type of PCI bridge that the handle points to, use the appropriate interface to return the struct pci_bus correctly. Reviewed-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
-
Alex Chiang authored
We can simplify ACPI drivers if we can tell whether a handle is an ACPI PCI root or not. Reviewed-by:
-
Jesse Barnes authored
The current mp_bus_to_node array is initialized only by AMD specific code, since AMD platforms have registers that can be used for determining mode numbers. On new Intel platforms it's necessary to initialize this array as well though, otherwise all PCI node numbers will be 0, when in fact they should be -1 (indicating that I/O isn't tied to any particular node). So move the mp_bus_to_node code into the common PCI code, and initialize it early with a default value of -1. This may be overridden later by arch code (e.g. the AMD code). With this change, PCI consistent memory and other node specific allocations (e.g. skbuff allocs) should occur on the "current" node. If, for performance reasons, applications want to be bound to specific nodes, they should open their devices only after being pinned to the CPU where they'll run, for maximum locality. Acked-by:
Jesse Brandeburg <jesse.brandeburg@gmail.com> Signed-off-by:
-
Jesse Barnes authored
yenta needs this for example. Acked-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Matthew Wilcox authored
Instead of open-coding pci_find_parent_resource and request_resource, just call pci_claim_resource. Signed-off-by:
-
Matthew Wilcox authored
Instead of open-coding pci_find_parent_resource and request_resource, just call pci_claim_resource. Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Alex Chiang authored
This was #define'd as 0 on all platforms, so let's get rid of it. This change makes pci_scan_slot() slightly easier to read. Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Tony Luck <tony.luck@intel.com> Cc: David Howells <dhowells@redhat.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Reviewed-by:
Russell King <linux@arm.linux.org.uk> Acked-by:
Ralf Baechle <ralf@linux-mips.org> Acked-by:
Kyle McMartin <kyle@mcmartin.ca> Acked-by:
Paul Mundt <lethal@linux-sh.org> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ed Cashin authored
Andy Whitcroft reported an oops in aoe triggered by use of an incorrectly initialised request_queue object: [ 2645.959090] kobject '<NULL>' (ffff880059ca22c0): tried to add an uninitialized object, something is seriously wrong. [ 2645.959104] Pid: 6, comm: events/0 Not tainted 2.6.31-5-generic #24-Ubuntu [ 2645.959107] Call Trace: [ 2645.959139] [<ffffffff8126ca2f>] kobject_add+0x5f/0x70 [ 2645.959151] [<ffffffff8125b4ab>] blk_register_queue+0x8b/0xf0 [ 2645.959155] [<ffffffff8126043f>] add_disk+0x8f/0x160 [ 2645.959161] [<ffffffffa01673c4>] aoeblk_gdalloc+0x164/0x1c0 [aoe] The request queue of an aoe device is not used but can be allocated in code that does not sleep. Bruno bisected this regression down to cd43e26f block: Expose stacked device queues in sysfs "This seems to generate /sys/block/$device/queue and its contents for everyone who is using queues, not just for those queues that have a non-NULL queue->request_fn." Addresses http://bugs.launchpad.net/bugs/410198 Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13942 Note that embedding a queue inside another object has always been an illegal construct, since the queues are reference counted and must persist until the last reference is dropped. So aoe was always buggy in this respect (Jens). Signed-off-by:
Ed Cashin <ecashin@coraid.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Bruno Premont <bonbons@linux-vserver.org> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com>
-
Linus Torvalds authored
Reinette Chatre reports a frozen system (with blinking keyboard LEDs) when switching from graphics mode to the text console, or when suspending (which does the same thing). With netconsole, the oops turned out to be BUG: unable to handle kernel NULL pointer dereference at 0000000000000084 IP: [<ffffffffa03ecaab>] i915_driver_irq_handler+0x26b/0xd20 [i915] and it's due to the i915_gem.c code doing drm_irq_uninstall() after having done i915_gem_idle(). And the i915_gem_idle() path will do i915_gem_idle() -> i915_gem_cleanup_ringbuffer() -> i915_gem_cleanup_hws() -> dev_priv->hw_status_page = NULL; but if an i915 interrupt comes in after this stage, it may want to access that hw_status_page, and gets the above NULL pointer dereference. And since the NULL pointer dereference happens from within an interrupt, and with the screen still in graphics mode, the common end result is simply a silently hung machine. Fix it by simply uninstalling the irq handler before idling rather than after. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13819Reported-and-tested-by:Reinette Chatre <reinette.chatre@intel.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 08 Sep, 2009 1 commit
-
-
Zhenyu Wang authored
eDP is exclusive connector too, and add missing crtc_mask setting for TV. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=14139Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Reported-and-tested-by:
Carlos R. Mafra <crmafra2@gmail.com> Signed-off-by:
-
