user/sven/linux.git/drivers/gpu, branch v3.2.82

drm/radeon: fix asic initialization for virtualized environments

2016-08-22T21:37:14Z

commit 05082b8bbd1a0ffc74235449c4b8930a8c240f85 upstream. When executing in a PCI passthrough based virtuzliation environment, the hypervisor will usually attempt to send a PCIe bus reset signal to the ASIC when the VM reboots. In this scenario, the card is not correctly initialized, but we still consider it to be posted. Therefore, in a passthrough based environemnt we should always post the card to guarantee it is in a good state for driver initialization. Ported from amdgpu commit: amdgpu: fix asic initialization for virtualized environments Cc: Andres Rodriguez Cc: Alex Williamson Signed-off-by: Alex Deucher [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

drm/radeon: make sure vertical front porch is at least 1

2016-06-15T20:28:14Z

commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b upstream. hw doesn't like a 0 value. Signed-off-by: Alex Deucher [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

drm/i915: Fix system resume if PCI device remained enabled

2016-06-15T20:28:13Z

commit dab9a2663f4e688106c041f7cd2797a721382f0a upstream. During system resume we depended on pci_enable_device() also putting the device into PCI D0 state. This won't work if the PCI device was already enabled but still in D3 state. This is because pci_enable_device() is refcounted and will not change the HW state if called with a non-zero refcount. Leaving the device in D3 will make all subsequent device accesses fail. This didn't cause a problem most of the time, since we resumed with an enable refcount of 0. But it fails at least after module reload because after that we also happen to leak a PCI device enable reference: During probing we call drm_get_pci_dev() which will enable the PCI device, but during device removal drm_put_dev() won't disable it. This is a bug of its own in DRM core, but without much harm as it only leaves the PCI device enabled. Fixing it is also a bit more involved, due to DRM mid-layering and because it affects non-i915 drivers too. The fix in this patch is valid regardless of the problem in DRM core. v2: - Add a code comment about the relation of this fix to the freeze/thaw vs. the suspend/resume phases. (Ville) - Add a code comment about the inconsistent ordering of set power state and device enable calls. (Chris) CC: Ville Syrjälä CC: Chris Wilson Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com (cherry picked from commit 44410cd0bfb26bde9288da34c190cc9267d42a20) Signed-off-by: Jani Nikula [bwh: Backported to 3.2: - Return error code directly - Adjust context] Signed-off-by: Ben Hutchings

drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.

2016-04-30T22:05:17Z

commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream. As observed on Apple iMac10,1, DCE-3.2, RV-730, link rate of 2.7 Ghz is not selected, because the args.v1.ucConfig flag setting for 2.7 Ghz gets overwritten by a following assignment of the transmitter to use. Move link rate setup a few lines down to fix this. In practice this didn't have any positive or negative effect on display setup on the tested iMac10,1 so i don't know if backporting to stable makes sense or not. Signed-off-by: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings

Revert "drm/radeon: call hpd_irq_event on resume"

2016-04-01T00:54:37Z

commit 256faedcfd646161477d47a1a78c32a562d2e845 upstream. This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9. It turns out that commit can cause problems for systems with multiple GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid graphics. This got noticed originally in 4.4.4, where this patch had already gotten back-ported, but 4.5-rc7 was verified to have the same problem. Alexander Deucher says: "It looks like you have a muxed system so I suspect what's happening is that one of the display is being reported as connected for both the IGP and the dGPU and then the desktop environment gets confused or there some sort problem in the detect functions since the mux is not switched to the dGPU. I don't see an easy fix unless Dave has any ideas. I'd say just revert for now" Reported-by: Jörg-Volker Peetz Acked-by: Alexander Deucher Cc: Dave Airlie Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

drm/i915: fix error path in intel_setup_gmbus()

2016-04-01T00:54:31Z

commit ed3f9fd1e865975ceefdb2a43b453e090b1fd787 upstream. This fails to undo the setup for pin==0; moreover, something interesting happens if the setup failed already at pin==0. Signed-off-by: Rasmus Villemoes Fixes: f899fc64cda8 ("drm/i915: use GMBUS to manage i2c links") Signed-off-by: Jani Nikula Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk (cherry picked from commit 2417c8c03f508841b85bf61acc91836b7b0e2560) Signed-off-by: Jani Nikula [bwh: Backported to 3.2: index variable is i, not pin] Signed-off-by: Ben Hutchings

drm/vmwgfx: respect 'nomodeset'

2016-02-27T14:28:44Z

commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 upstream. Signed-off-by: Rob Clark Reviewed-by: Thomas Hellstrom . Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings

drm/radeon: clean up fujitsu quirks

2016-02-13T10:34:05Z

commit 0eb1c3d4084eeb6fb3a703f88d6ce1521f8fcdd1 upstream. Combine the two quirks. bug: https://bugzilla.kernel.org/show_bug.cgi?id=109481 Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings

drm/radeon: call hpd_irq_event on resume

2016-02-13T10:34:04Z

commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9 upstream. Need to call this on resume if displays changes during suspend in order to properly be notified of changes. Signed-off-by: Alex Deucher [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

drm/radeon: fix hotplug race at startup

2016-01-22T21:40:08Z

commit 7f98ca454ad373fc1b76be804fa7138ff68c1d27 upstream. We apparantly get a hotplug irq before we've initialised modesetting, [drm] Loading R100 Microcode BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] __mutex_lock_slowpath+0x23/0x91 *pde = 00000000 Oops: 0002 [#1] Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf67402 #111 Hardware name: MicroLink /D850MV , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003 Workqueue: events radeon_hotplug_work_func [radeon] task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000 EIP: 0060:[] EFLAGS: 00010282 CPU: 0 EIP is at __mutex_lock_slowpath+0x23/0x91 EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0 Stack: f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940 Call Trace: [] ? dequeue_task_fair+0xa4/0xb7 [] ? mutex_lock+0x9/0xa [] ? radeon_hotplug_work_func+0x17/0x57 [radeon] [] ? process_one_work+0xfc/0x194 [] ? worker_thread+0x18d/0x218 [] ? rescuer_thread+0x1d5/0x1d5 [] ? kthread+0x7b/0x80 [] ? ret_from_kernel_thread+0x20/0x30 [] ? init_completion+0x18/0x18 Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63 Reported-and-Tested-by: Meelis Roos Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings