summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2011-02-17xhci: Use GFP_NOIO during device reset.Sarah Sharp
commit a6d940dd759bf240d28624198660ed34582a327b upstream. When xhci_discover_or_reset_device() is called after a host controller power loss, the virtual device may need to be reallocated. Make sure xhci_alloc_dev() uses GFP_NOIO. This avoid causing a deadlock by allowing the kernel to flush pending I/O while reallocating memory for a virtual device for a USB mass storage device that's holding the backing store for dirty memory buffers. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17usb: Realloc xHCI structures after a hub is verified.Sarah Sharp
commit 653a39d1f61bdc9f277766736d21d2e9be0391cb upstream. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17xhci: Do not run xhci_cleanup_msix with irq disabledZhang Rui
commit 40a9fb17f32dbe54de3d636142a59288544deed7 upstream. when unloading xhci_hcd, I got: [ 134.856813] xhci_hcd 0000:02:00.0: remove, state 4 [ 134.858140] usb usb3: USB disconnect, address 1 [ 134.874956] xhci_hcd 0000:02:00.0: Host controller not halted, aborting reset. [ 134.876351] BUG: sleeping function called from invalid context at kernel/mutex.c:85 [ 134.877657] in_atomic(): 0, irqs_disabled(): 1, pid: 1451, name: modprobe [ 134.878975] Pid: 1451, comm: modprobe Not tainted 2.6.37-rc5+ #162 [ 134.880298] Call Trace: [ 134.881602] [<ffffffff8104156a>] __might_sleep+0xeb/0xf0 [ 134.882921] [<ffffffff814763dc>] mutex_lock+0x24/0x50 [ 134.884229] [<ffffffff810a745c>] free_desc+0x2e/0x5f [ 134.885538] [<ffffffff810a74c8>] irq_free_descs+0x3b/0x71 [ 134.886853] [<ffffffff8102584d>] free_irq_at+0x31/0x36 [ 134.888167] [<ffffffff8102723f>] destroy_irq+0x69/0x71 [ 134.889486] [<ffffffff8102747a>] native_teardown_msi_irq+0xe/0x10 [ 134.890820] [<ffffffff8124c382>] default_teardown_msi_irqs+0x57/0x80 [ 134.892158] [<ffffffff8124be46>] free_msi_irqs+0x8b/0xe9 [ 134.893504] [<ffffffff8124cd46>] pci_disable_msix+0x35/0x39 [ 134.894844] [<ffffffffa01b444a>] xhci_cleanup_msix+0x31/0x51 [xhci_hcd] [ 134.896186] [<ffffffffa01b4b3a>] xhci_stop+0x3a/0x80 [xhci_hcd] [ 134.897521] [<ffffffff81341dd4>] usb_remove_hcd+0xfd/0x14a [ 134.898859] [<ffffffff813500ae>] usb_hcd_pci_remove+0x5c/0xc6 [ 134.900193] [<ffffffff8123c606>] pci_device_remove+0x3f/0x91 [ 134.901535] [<ffffffff812e7ea4>] __device_release_driver+0x83/0xd9 [ 134.902899] [<ffffffff812e8571>] driver_detach+0x86/0xad [ 134.904222] [<ffffffff812e7d56>] bus_remove_driver+0xb2/0xd8 [ 134.905540] [<ffffffff812e8633>] driver_unregister+0x6c/0x74 [ 134.906839] [<ffffffff8123c8e4>] pci_unregister_driver+0x44/0x89 [ 134.908121] [<ffffffffa01b940e>] xhci_unregister_pci+0x15/0x17 [xhci_hcd] [ 134.909396] [<ffffffffa01bd7d2>] xhci_hcd_cleanup+0xe/0x10 [xhci_hcd] [ 134.910652] [<ffffffff8107fcd1>] sys_delete_module+0x1ca/0x23b [ 134.911882] [<ffffffff81123932>] ? path_put+0x22/0x26 [ 134.913104] [<ffffffff8109a800>] ? audit_syscall_entry+0x2c/0x148 [ 134.914333] [<ffffffff8100ac82>] system_call_fastpath+0x16/0x1b [ 134.915658] xhci_hcd 0000:02:00.0: USB bus 3 deregistered [ 134.916465] xhci_hcd 0000:02:00.0: PCI INT A disabled and the same issue when xhci_suspend is invoked. (Note from Sarah: That's fixed by Andiry's patch before this, by synchronizing the irqs rather than freeing them on suspend.) Do not run xhci_cleanup_msix with irq disabled. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17xHCI: synchronize irq in xhci_suspend()Andiry Xu
commit 0029227f1bc30b6c809ae751f9e7af6cef900997 upstream. Synchronize the interrupts instead of free them in xhci_suspend(). This will prevent a double free when the host is suspended and then the card removed. Set the flag hcd->msix_enabled when using MSI-X, and check the flag in suspend_common(). MSI-X synchronization will be handled by xhci_suspend(), and MSI/INTx will be synchronized in suspend_common(). This patch should be queued for the 2.6.37 stable tree. Reported-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17xhci: Resume bus on any port status change.Sarah Sharp
commit 7111ebc97ed53a32314011c85a6f235f0dab8ae8 upstream. The original code that resumed the USB bus on a port status change would only do so when there was a device connected to the port. If a device was just disconnected, the event would be queued for khubd, but khubd wouldn't run. That would leave the connect status change (CSC) bit set. If a USB device was plugged into that same port, the xHCI host controller would set the current connect status (CCS) bit. But since the CSC bit was already set, it would not generate an interrupt for a port status change event. That would mean the user could "Safely Remove" a device, have the bus suspend, disconnect the device, re-plug it in, and then the device would never be enumerated. Plugging in a different device on another port would cause the bus to resume, and khubd would notice the re-connected device. Running lsusb would also resume the bus, leading users to report the problem "went away" when using diagnostic tools. The solution is to resume the bus when a port status change event is received, regardless of the port status. Thank you very much to Maddog for helping me track down this Heisenbug. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Jon 'maddog' Hall <maddog@li.org> Tested-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915: Only bind to function 0 of the PCI deviceChris Wilson
commit 5fe49d86f9d01044abf687a8cd21edef636d58aa upstream. Early chipsets (gen2/3) used function 1 as a placeholder for multi-head. We used to ignore these since they were not assigned to PCI_CLASS_DISPLAY_VGA. However with 934f992c7 we attempt to bind to all Intel PCI_CLASS_DISPLAY devices (and functions) to work in multi-gpu systems. This fails hard on gen2/3. Reported-by: Ferenc Wágner <wferi@niif.hu> Tested-by: Ferenc Wágner <wferi@niif.hu> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28012 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17agp: ensure GART has an address before enabling itStephen Kitt
commit a70b95c017e8b518e1e069853355e4e497453dbb upstream. Some BIOSs (eg. the AMI BIOS on the Asus P4P800 motherboard) don't initialise the GART address, and pcibios_assign_resources() can ignore it because it can be marked as a host bridge (see https://bugzilla.kernel.org/show_bug.cgi?id=24392#c5 for details). This was handled correctly up to 2.6.35, but the pci_enable_device() cleanup in 2.6.36 96576a9e1a0cdb8 ("agp: intel-agp: do not use PCI resources before pci_enable_device()") means that the kernel tries to enable the GART before assigning it an address; in such cases the GART overlaps with other device assignments and ends up being disabled. This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=24392 Note that I imagine efficeon-agp.c probably has the same problem, but I can't test that and I'd like to make sure this patch is suitable for -stable (since 2.6.36 and 2.6.37 are affected). Signed-off-by: Stephen Kitt <steve@sk2.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Maciej Rutecki <maciej.rutecki@gmail.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Kulikov Vasiliy <segooon@gmail.com> Cc: Florian Mickler <florian@mickler.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm: Only set DPMS ON when actually configuring a modeKeith Packard
commit 811aaa55ba21ab37407018cfc01770d6b037d3fb upstream. In drm_crtc_helper_set_config, instead of always forcing all outputs to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a mode set, as any mode set will turn all outputs on. This fixes https://lkml.org/lkml/2011/1/24/457 Signed-off-by: Keith Packard <keithp@keithp.com> Reported-and-tested-by: Carlos R. Mafra <crmafra2@gmail.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915: Recognise non-VGA display devicesChris Wilson
commit 934f992c763ae1e5eefcce8af769c16444085df7 upstream. Starting with SandyBridge (though possible with earlier hacked BIOSes), the BIOS may initialise the IGFX as secondary to a discrete GPU. Prior, it would simply disable the integrated GPU. So we adjust our PCI class mask to match any DISPLAY_CLASS device. In such a configuration, the IGFX is not a primary VGA controller and so should not take part in VGA arbitration, and the error return from vga_client_register() is expected. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915: Add dependency on CONFIG_TMPFSChris Wilson
commit f7ab9b407b3bc83161c2aa74c992ba4782e87c9c upstream. Without tmpfs, shmem_readpage() is not compiled in causing an OOPS as soon as we try to allocate some swappable pages for GEM. Jan 19 22:52:26 harlie kernel: Modules linked in: i915(+) drm_kms_helper cfbcopyarea video backlight cfbimgblt cfbfillrect Jan 19 22:52:26 harlie kernel: Jan 19 22:52:26 harlie kernel: Pid: 1125, comm: modprobe Not tainted 2.6.37Harlie #10 To be filled by O.E.M./To be filled by O.E.M. Jan 19 22:52:26 harlie kernel: EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 3 Jan 19 22:52:26 harlie kernel: EIP is at 0x0 Jan 19 22:52:26 harlie kernel: EAX: 00000000 EBX: f7b7d000 ECX: f3383100 EDX: f7b7d000 Jan 19 22:52:26 harlie kernel: ESI: f1456118 EDI: 00000000 EBP: f2303c98 ESP: f2303c7c Jan 19 22:52:26 harlie kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jan 19 22:52:26 harlie kernel: Process modprobe (pid: 1125, ti=f2302000 task=f259cd80 task.ti=f2302000) Jan 19 22:52:26 harlie kernel: Stack: Jan 19 22:52:26 harlie udevd-work[1072]: '/sbin/modprobe -b pci:v00008086d00000046sv00000000sd00000000bc03sc00i00' unexpected exit with status 0x0009 Jan 19 22:52:26 harlie kernel: c1074061 000000d0 f2f42b80 00000000 000a13d2 f2d5dcc0 00000001 f2303cac Jan 19 22:52:26 harlie kernel: c107416f 00000000 000a13d2 00000000 f2303cd4 f8d620ed f2cee620 00001000 Jan 19 22:52:26 harlie kernel: 00000000 000a13d2 f1456118 f2d5dcc0 f1a40000 00001000 f2303d04 f8d637ab Jan 19 22:52:26 harlie kernel: Call Trace: Jan 19 22:52:26 harlie kernel: [<c1074061>] ? do_read_cache_page+0x71/0x160 Jan 19 22:52:26 harlie kernel: [<c107416f>] ? read_cache_page_gfp+0x1f/0x30 Jan 19 22:52:26 harlie kernel: [<f8d620ed>] ? i915_gem_object_get_pages+0xad/0x1d0 [i915] Jan 19 22:52:26 harlie kernel: [<f8d637ab>] ? i915_gem_object_bind_to_gtt+0xeb/0x2d0 [i915] Jan 19 22:52:26 harlie kernel: [<f8d65961>] ? i915_gem_object_pin+0x151/0x190 [i915] Jan 19 22:52:26 harlie kernel: [<c11e16ed>] ? drm_gem_object_init+0x3d/0x60 Jan 19 22:52:26 harlie kernel: [<f8d65aa5>] ? i915_gem_init_ringbuffer+0x105/0x1e0 [i915] Jan 19 22:52:26 harlie kernel: [<f8d571b7>] ? i915_driver_load+0x667/0x1160 [i915] Reported-by: John J. Stimson-III <john@idsfa.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDSKnut Petersen
commit 22ab70d3262ddb6e69b3c246a34e2967ba5eb1e8 upstream. Signed-off-by: Knut Petersen <knut_petersen@t-online.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915/panel: The backlight is enabled if the current value is non-zeroIndan Zupancic
commit c8303e7f3f3093c16ef0fa5f73280637c89d4368 upstream. ... and not if the maximum is non-zero. This fixes the typo introduced in 47356eb6728501452 and preserves the backlight value from boot. [ickle: My thanks also to Indan Zupancic for diagnosing the original regression and suggesting the appropriate fix.] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915/panel: Only record the backlight level when it is enabledChris Wilson
commit 47356eb67285014527a5ab87543ba1fae3d1e10a upstream. By tracking the current status of the backlight we can prevent recording the value of the current backlight when we have disabled it. And so prevent restoring it to 'off' after an unbalanced sequence of intel_lvds_disable/enable. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=22672 Tested-by: Alex Riesen <raa.lkml@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915: fix calculation of eDP signal levels on SandybridgeYuanhan Liu
commit 3c5a62b5226ca5db993660281e9c2a7275d9fb02 upstream. Some voltage swing/pre-emphasis level use the same value on eDP Sandybridge, like 400mv_0db and 600mv_0db are with the same value of (0x0 << 22). So, fix them, and point out the value if it isn't a supported voltage swing/pre-emphasis level. Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915/crt: Check for a analog monitor in case of DVI-IDavid Müller
commit f5afcd3dd0dca7fe869311c51da54d5a889191ba upstream. Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is not working any longer. The analog output is always activated regardless of the type of monitor attached. The culprit seems to be intel_crt_detect_ddc(), which returns true as soon as an ACK from the EDID device is received. Obviously this approach does not work with DVI-I where the analog and digital outputs share a common DDC bus. In a similar manner to the shared DDC wire, ala the "Mac Mini Hack", we need an additional check to make sure that there really is an analog device attached to the DDC. Signed-off-by: David Müller <d.mueller@elsoft.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915/sdvo: Defer detection of output capabilities until probingChris Wilson
commit 97aaf910731b03b27b1c4c8a58006a1dc99dcd9a upstream. Alex Fiestas reported an issue with his HDMI connector being misdetected as DVI unless he had something connected upon boot. By moving the decision as to whether to use HDMI or DVI encoding for the HDMI capable output until we probe the monitor means that we should avoid sending a HDMI signal to a DVI monitor and also correctly detect hardware like Alex's. However, to really determine what connector is soldered onto the wire we need to inspect the VBT sdvo child devices - but can we trust it? Reported-by: Alex Fiestas <alex@eyeos.org> Tested-by: Alex Fiestas <alex@eyeos.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/i915: check eDP encoder correctly when setting modesJesse Barnes
commit 858bc21f0637c407601a05626854ae58b242f75d upstream. We were using a stale pointer in the check which caused us to use CPU attached DP params when we should have been using PCH attached params. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988 Tested-by: Jan-Hendrik Zab <jan@jhz.name> Tested-by: Christoph Lukas <christoph.lukas@gmx.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm: Restore the old_fb upon modeset failureChris Wilson
commit 0ba41e449fd0f45f5b29c1009020ab1b298bedda upstream. ... or else we may end up disabling the wrong framebuffer, leading to an OOPS, e.g: [ 6033.229012] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3271! [ 6033.229012] invalid opcode: 0000 [#1] SMP [ 6033.229012] last sysfs file: /sys/devices/virtual/backlight/acpi_video0/uevent [ 6033.229012] Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq mperf snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer thinkpad_acpi ppdev snd r852 sm_common iTCO_wdt uvcvideo i2c_i801 iTCO_vendor_support microcode wmi nand videodev nand_ids nand_ecc snd_page_alloc parport_pc parport mtd soundcore joydev v4l1_compat pcspkr uinput ipv6 sdhci_pci sdhci mmc_core yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 6033.229012] [ 6033.229012] Pid: 4834, comm: Xorg Not tainted 2.6.37-rc8+ #25 7661BL5/7661BL5 [ 6033.229012] EIP: 0060:[<f86fda5e>] EFLAGS: 00013246 CPU: 0 [ 6033.229012] EIP is at i915_gem_object_unpin+0x23/0x76 [i915] [ 6033.229012] EAX: f68a4000 EBX: f6831f00 ECX: 000600fa EDX: f68a8000 [ 6033.229012] ESI: f68a4014 EDI: f68a42b8 EBP: f2169c44 ESP: f2169c3c [ 6033.229012] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 6033.229012] Process Xorg (pid: 4834, ti=f2168000 task=f21c8000 task.ti=f2168000) [ 6033.229012] Stack: [ 6033.229012] f3a84800 f68a4014 f2169c54 f87045d8 f3a84800 f872d9a8 f2169c68 f7fd8091 [ 6033.229012] f3b952a4 00000000 f68a414c f2169cf0 f7fd9377 00000000 00000000 f7fd98b0 [ 6033.229012] f7fd9f4e 0000000f f7f328a0 00000000 00000000 00000000 f2169ca4 f68a414c [ 6033.229012] Call Trace: [ 6033.229012] [<f87045d8>] ? intel_crtc_disable+0x36/0x41 [i915] [ 6033.229012] [<f7fd8091>] ? drm_helper_disable_unused_functions+0xcd/0xf9 [drm_kms_helper] [ 6033.229012] [<f7fd9377>] ? drm_crtc_helper_set_config+0x62a/0x7f7 [drm_kms_helper] [ 6033.229012] [<c04daa10>] ? __slab_free+0x1b/0xa4 [ 6033.229012] [<f7fd7e62>] ? drm_fb_helper_initial_config+0x466/0x497 [drm_kms_helper] [ 6033.229012] [<f7fd7ea3>] ? drm_fb_helper_restore+0x10/0x2a [drm_kms_helper] [ 6033.229012] [<f86f2577>] ? i915_driver_lastclose+0x2a/0x57 [i915] [ 6033.229012] [<f7f1989f>] ? drm_lastclose+0x45/0x23e [drm] [ 6033.229012] [<f7f1a0b4>] ? drm_release+0x462/0x4d7 [drm] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: fix s/r issues with bios scratch regsAlex Deucher
commit 87364760de5d631390c478fcbac8db1b926e0adf upstream. The accelerate mode bit gets checked by certain atom command tables to set up some register state. It needs to be clear when setting modes and set when not. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26942 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms/evergreen: always set certain VGT regs at CP initAlex Deucher
commit 18ff84da29b3f0c073e0ce6e341663cc6bcb0ab7 upstream. These should be handled by the clear_state setup, but set them directly as well just to be sure. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: Enable new pll calculation for avivo+ asicsAlex Deucher
commit 619efb105924d8cafa0c1dd9389e9ab506f5425d upstream. New algo is used for r5xx+ and legacy is used for r1xx-r4xx, rv515. I've tested on all relevant GPUs and monitors that I have access to and have found no problems. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26562 https://bugzilla.kernel.org/show_bug.cgi?id=26552 May fix: https://bugs.freedesktop.org/show_bug.cgi?id=32556 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: add new pll algo for avivo asicsAlex Deucher
commit f523f74eac1897b13c05c88ce6e5de0a7c34578b upstream. Based on the vbios code. This should hopefully fix the pll problems on a number of avivo asics once it's enabled. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: add pll debugging outputAlex Deucher
commit 51d4bf840a27fe02c883ddc6d9708af056773769 upstream. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: switch back to min->max pll post divider iterationAlex Deucher
commit a6f9761743bf35b052180f4a8bdae4d2cc0465f6 upstream. Seems more reliable. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26552 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: re-emit full context state for evergreen blitsAlex Deucher
commit 1e644d6dce366a7bae22484f60133b61ba322911 upstream. clear state doesn't seem to work properly in some cases Fixes hangs in heavy 3D on some evergreen cards reported on IRC. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=33381 possibly others. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17radeon/kms: fix dp displayport mode validationJerome Glisse
commit 6bba2e116808ca12e30c8d88dfedabf8b8d67390 upstream. Check if there is a big enough dp clock & enough dp lane to drive the video mode provided. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-By: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: make the mac rv630 quirk genericAlex Deucher
commit be23da8ad219650517cbbb7acbeaeb235667113a upstream. Seems some other boards do this as well. Reported-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: adjust quirk for acer laptopAlex Deucher
commit 2f299d5de02da3ffb1f9e1a05c91dcd1173ebd3c upstream. Acer laptop (TravelMate 5730G) has an HDMI connector on the laptop and a DVI connector on the docking station and both share the same encoder, hpd pin, and ddc line. The bios connector table reflects this and is technically correct, however, we drop the DVI connector here since xrandr has no concept of encoders (only crtcs and connectors) and will try and drive both connectors with different crtcs which isn't possible on the hardware side and leaves no crtcs for LVDS or VGA. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=32732 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17drm/radeon/kms: add quirk for Mac Radeon HD 2600 cardAlex Deucher
commit f598aa7593427ffe3a61e7767c34bd695a5e7ed0 upstream. Reported-by: 屋国遥 <hyagni@gmail.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17net/fec: fix MMFR_OP type in fec_enet_mdio_writeShawn Guo
commit 862f0982eadcea0e114576c57ea426d3d51a69a6 upstream. FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in a mdio write operation. It's probably a typo introduced by commit: e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8 netdev/fec.c: add phylib supporting to enable carrier detection (v2) Signed-off-by: Shawn Guo <shawn.guo@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17dm mpath: disable blk_abort_queueMike Snitzer
commit 09c9d4c9b6a2b5909ae3c6265e4cd3820b636863 upstream. Revert commit 224cb3e981f1b2f9f93dbd49eaef505d17d894c2 dm: Call blk_abort_queue on failed paths Multipath began to use blk_abort_queue() to allow for lower latency path deactivation. This was found to cause list corruption: the cmd gets blk_abort_queued/timedout run on it and the scsi eh somehow is able to complete and run scsi_queue_insert while scsi_request_fn is still trying to process the request. https://www.redhat.com/archives/dm-devel/2010-November/msg00085.html Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Cc: Mike Anderson <andmike@linux.vnet.ibm.com> Cc: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17dm: dont take i_mutex to change device sizeMike Snitzer
commit c217649bf2d60ac119afd71d938278cffd55962b upstream. No longer needlessly hold md->bdev->bd_inode->i_mutex when changing the size of a DM device. This additional locking is unnecessary because i_size_write() is already protected by the existing critical section in dm_swap_table(). DM already has a reference on md->bdev so the associated bd_inode may be changed without lifetime concerns. A negative side-effect of having held md->bdev->bd_inode->i_mutex was that a concurrent DM device resize and flush (via fsync) would deadlock. Dropping md->bdev->bd_inode->i_mutex eliminates this potential for deadlock. The following reproducer no longer deadlocks: https://www.redhat.com/archives/dm-devel/2009-July/msg00284.html Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17mtd: pxa3xx_nand: NULL dereference in pxa3xx_nand_probeDan Carpenter
commit 52d039fdaa78c5a9f9bc2940ad58d7ed76b8336d upstream. "info->cmdset" gets dereferenced in __readid() so it needs to be initialized earlier in the function. This bug was introduced in 18c81b1828f8 "mtd: pxa3xx_nand: remove the flash info in driver structure". Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17x86, dmi, debug: Log board name (when present) in dmesg/oops outputNaga Chumbalkar
commit 84e383b322e5348db03be54ff64cc6da87003717 upstream. The "Type 2" SMBIOS record that contains Board Name is not strictly required and may be absent in the SMBIOS on some platforms. ( Please note that Type 2 is not listed in Table 3 in Sec 6.2 ("Required Structures and Data") of the SMBIOS v2.7 Specification. ) Use the Manufacturer Name (aka System Vendor) name. Print Board Name only when it is present. Before the fix: (i) dmesg output: DMI: /ProLiant DL380 G6, BIOS P62 01/29/2011 (ii) oops output: Pid: 2170, comm: bash Not tainted 2.6.38-rc4+ #3 /ProLiant DL380 G6 After the fix: (i) dmesg output: DMI: HP ProLiant DL380 G6, BIOS P62 01/29/2011 (ii) oops output: Pid: 2278, comm: bash Not tainted 2.6.38-rc4+ #4 HP ProLiant DL380 G6 Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com> LKML-Reference: <20110214224423.2182.13929.sendpatchset@nchumbalkar.americas.hpqcorp.net> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17Input: sysrq - ensure sysrq_enabled and __sysrq_enabled are consistentAndy Whitcroft
commit 8c6a98b22b750c9eb52653ba643faa17db8d3881 upstream. Currently sysrq_enabled and __sysrq_enabled are initialised separately and inconsistently, leading to sysrq being actually enabled by reported as not enabled in sysfs. The first change to the sysfs configurable synchronises these two: static int __read_mostly sysrq_enabled = 1; static int __sysrq_enabled; Add a common define to carry the default for these preventing them becoming out of sync again. Default this to 1 to mirror previous behaviour. Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17Revert "Input: do not pass injected events back to the originating handler"Dmitry Torokhov
commit 9ae4345a46bdb148e32a547e89ff29563a11e127 upstream. This reverts commit 5fdbe44d033d059cc56c2803e6b4dbd8cb4e5e39. Apparently there exist userspace programs that expect to be able to "loop back" and distribute to readers events written into /dev/input/eventX and this change made for the benefit of SysRq handler broke them. Now that SysRq uses alternative method to suppress filtering of the events it re-injects we can safely revert this change. Reported-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17Input: sysrq - rework re-inject logicDmitry Torokhov
commit 7ab7b5adfb923978a2cab7bd3fac9ccf7d21cc3f upstream. Internally 'disable' the filter when re-injecting Alt-SysRq instead of relying on input core to suppress delivery of injected events to the originating handler. This allows to revert commit 5fdbe44d033d059cc56c2803e6b4dbd8cb4e5e39 which causes problems with existing userspace programs trying to loopback the events via evdev. Reported-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17tpm_tis: Use timeouts returned from TPMStefan Berger
commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. The current TPM TIS driver in git discards the timeout values returned from the TPM. The check of the response packet needs to consider that the return_code field is 0 on success and the size of the expected packet is equivalent to the header size + u32 length indicator for the TPM_GetCapability() result + 3 timeout indicators of type u32. I am also adding a sysfs entry 'timeouts' showing the timeouts that are being used. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Tested-by: Guillaume Chazarain <guichaz@gmail.com> Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17TPM: Long default timeout fixRajiv Andrade
commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. If duration variable value is 0 at this point, it's because chip->vendor.duration wasn't filled by tpm_get_timeouts() yet. This patch sets then the lowest timeout just to give enough time for tpm_get_timeouts() to further succeed. This fix avoids long boot times in case another entity attempts to send commands to the TPM when the TPM isn't accessible. Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17tpm: fix panic caused by "tpm: Autodetect itpm devices"Olof Johansson
commit e5cce6c13c25d9ac56955a3ae2fd562719848172 upstream. commit 3f0d3d016d89a5efb8b926d4707eb21fa13f3d27 adds a check for PNP device id to the common tpm_tis_init() function, which in some cases (force=1) will be called without the device being a member of a pnp_dev. Oopsing and panics ensue. Move the test up to before the call to tpm_tis_init(), since it just modifies a global variable anyway. Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17PM / Runtime: Don't enable interrupts while running in_interruptAlan Stern
commit c3810c88788d505d4ffd786addd111b745e42161 upstream. This patch (as1445) fixes a bug in the runtime PM core left over from the addition of the no_callbacks flag. If this flag is set then it is possible for rpm_suspend() to be called in_interrupt, so when releasing spinlocks it's important not to re-enable interrupts. To avoid an unnecessary save-and-restore of the interrupt flag, the patch also inlines a pm_request_idle() call. This fixes Bugzilla #27482. (The offending code was added in 2.6.37, so it's not necessary to apply this to any earlier stable kernels.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: tim blechmann <tim@klingt.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17md_make_request: don't touch the bio after calling make_requestChris Mason
commit e91ece5590b3c728624ab57043fc7a05069c604a upstream. md_make_request was calling bio_sectors() for part_stat_add after it was calling the make_request function. This is bad because the make_request function can free the bio and because the bi_size field can change around. The fix here was suggested by Jens Axboe. It saves the sector count before the make_request call. I hit this with CONFIG_DEBUG_PAGEALLOC turned on while trying to break his pretty fusionio card. Signed-off-by: Chris Mason <chris.mason@oracle.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17pata_mpc52xx: inherit from ata_bmdma_port_opsTejun Heo
commit 77c5fd19075d299fe820bb59bb21b0b113676e20 upstream. pata_mpc52xx supports BMDMA but inherits ata_sff_port_ops which triggers BUG_ON() when a DMA command is issued. Fix it. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Roman Fietze <roman.fietze@telemotive.de> Cc: Sergei Shtylyov <sshtylyov@mvista.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17md: Fix removal of extra drives when converting RAID6 to RAID5NeilBrown
commit bf2cb0dab8c97f00a71875d9b13dbac17a2f47ca upstream. When a RAID6 is converted to a RAID5, the extra drive should be discarded. However it isn't due to a typo in a comparison. This bug was introduced in commit e93f68a1fc6 in 2.6.35-rc4 and is suitable for any -stable since than. As the extra drive is not removed, the 'degraded' counter is wrong and so the RAID5 will not respond correctly to a subsequent failure. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17md: Ensure no IO request to get md device before it is properly initialised.NeilBrown
commit 0ca69886a8273ac1350143d562280bfcbe4760dc upstream. When an md device is in the process of coming on line it is possible for an IO request (typically a partition table probe) to get through before the array is fully initialised, which can cause unexpected behaviour (e.g. a crash). So explicitly record when the array is ready for IO and don't allow IO through until then. There is no possibility for a similar problem when the array is going off-line as there must only be one 'open' at that time, and it is busy off-lining the array and so cannot send IO requests. So no memory barrier is needed in md_stop() This has been a bug since commit 409c57f3801 in 2.6.30 which introduced md_make_request. Before then, each personality would register its own make_request_fn when it was ready. This is suitable for any stable kernel from 2.6.30.y onwards. Signed-off-by: NeilBrown <neilb@suse.de> Reported-by: "Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17md: fix regression resulting in delays in clearing bits in a bitmapNeilBrown
commit 6c9879101442b08581e8a0e3ae6b7f643a78fd63 upstream. commit 589a594be1fb (2.6.37-rc4) fixed a problem were md_thread would sometimes call the ->run function at a bad time. If an error is detected during array start up after the md_thread has been started, the md_thread is killed. This resulted in the ->run function being called once. However the array may not be in a state that it is safe to call ->run. However the fix imposed meant that ->run was not called on a timeout. This means that when an array goes idle, bitmap bits do not get cleared promptly. While the array is busy the bits will still be cleared when appropriate so this is not very serious. There is no risk to data. Change the test so that we only avoid calling ->run when the thread is being stopped. This more explicitly addresses the problem situation. This is suitable for 2.6.37-stable and any -stable kernel to which 589a594be1fb was applied. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17md: fix regression with re-adding devices to arrays with no metadataNeilBrown
commit bf572541ab44240163eaa2d486b06f306a31d45a upstream. Commit 1a855a0606 (2.6.37-rc4) fixed a problem where devices were re-added when they shouldn't be but caused a regression in a less common case that means sometimes devices cannot be re-added when they should be. In particular, when re-adding a device to an array without metadata we should always access the device, but after the above commit we didn't. This patch sets the In_sync flag in that case so that the re-add succeeds. This patch is suitable for any -stable kernel to which 1a855a0606 was applied. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17hostap_cs: fix sleeping function called from invalid contextStanislaw Gruszka
commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream. pcmcia_request_irq() and pcmcia_enable_device() are intended to be called from process context (first function allocate memory with GFP_KERNEL, second take a mutex). We can not take spin lock and call them. It's safe to move spin lock after pcmcia_enable_device() as we still hold off IRQ until dev->base_addr is 0 and driver will not proceed with interrupts when is not ready. Patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=643758 Reported-and-tested-by: rbugz@biobind.com Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17backlight: fix 88pm860x_bl macro collisionRandy Dunlap
commit 2550326ac7a062fdfc204f9a3b98bdb9179638fc upstream. Fix collision with kernel-supplied #define: drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined arch/x86/include/asm/page_64_types.h:6:1: warning: this is the location of the previous definition Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Haojian Zhuang <haojian.zhuang@marvell.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-02-17nbd: remove module-level ioctl mutexSoren Hansen
commit de1f016f882e52facc3c8609599f827bcdd14af9 upstream. Commit 2a48fc0ab242417 ("block: autoconvert trivial BKL users to private mutex") replaced uses of the BKL in the nbd driver with mutex operations. Since then, I've been been seeing these lock ups: INFO: task qemu-nbd:16115 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. qemu-nbd D 0000000000000001 0 16115 16114 0x00000004 ffff88007d775d98 0000000000000082 ffff88007d775fd8 ffff88007d774000 0000000000013a80 ffff8800020347e0 ffff88007d775fd8 0000000000013a80 ffff880133730000 ffff880002034440 ffffea0004333db8 ffffffffa071c020 Call Trace: [<ffffffff815b9997>] __mutex_lock_slowpath+0xf7/0x180 [<ffffffff815b93eb>] mutex_lock+0x2b/0x50 [<ffffffffa071a21c>] nbd_ioctl+0x6c/0x1c0 [nbd] [<ffffffff812cb970>] blkdev_ioctl+0x230/0x730 [<ffffffff811967a1>] block_ioctl+0x41/0x50 [<ffffffff81175c03>] do_vfs_ioctl+0x93/0x370 [<ffffffff81175f61>] sys_ioctl+0x81/0xa0 [<ffffffff8100c0c2>] system_call_fastpath+0x16/0x1b Instrumenting the nbd module's ioctl handler with some extra logging clearly shows the NBD_DO_IT ioctl being invoked which is a long-lived ioctl in the sense that it doesn't return until another ioctl asks the driver to disconnect. However, that other ioctl blocks, waiting for the module-level mutex that replaced the BKL, and then we're stuck. This patch removes the module-level mutex altogether. It's clearly wrong, and as far as I can see, it's entirely unnecessary, since the nbd driver maintains per-device mutexes, and I don't see anything that would require a module-level (or kernel-level, for that matter) mutex. Signed-off-by: Soren Hansen <soren@linux2go.dk> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Acked-by: Paul Clements <paul.clements@steeleye.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.46.0) at 2026-02-25 07:20:52 +0000