1. 18 3月, 2015 6 次提交
    • A
      drm/radeon: drop ttm two ended allocation · a239118a
      Alex Deucher 提交于
      radeon_bo_create() calls radeon_ttm_placement_from_domain()
      before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
      uses the ttm bo size to determine when to select top down
      allocation but since the ttm bo is not initialized yet the
      check is always false.  It only took effect when buffers
      were validated later.  It also seemed to regress suspend
      and resume on some systems possibly due to it not
      taking effect in radeon_bo_create().
      
      radeon_bo_create() and radeon_ttm_placement_from_domain()
      need to be reworked substantially for this to be optimally
      effective.  Re-enable it at that point.
      Noticed-by: NOded Gabbay <oded.gabbay@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      a239118a
    • H
      drm/exynos: fix the initialization order in FIMD · cdbfca89
      Hyungwon Hwang 提交于
      Since commit 0f04cf8d ("drm/exynos:
      fix wrong pipe calculation for crtc"), fimd_clear_channel() can be
      called when is_drm_iommu_supported() returns true. In this case,
      the kernel is going to be panicked because crtc is not set yet.
      
      [    1.211156] [drm] Initialized drm 1.1.0 20060810
      [    1.216785] Unable to handle kernel NULL pointer dereference at virtual address 00000350
      [    1.223415] pgd = c0004000
      [    1.226086] [00000350] *pgd=00000000
      [    1.229649] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      [    1.234940] Modules linked in:
      [    1.237982] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1-00062-g7a7cc79-dirty #123
      [    1.246136] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [    1.252214] task: ee8c8000 ti: ee8d0000 task.ti: ee8d0000
      [    1.257606] PC is at fimd_wait_for_vblank+0x8/0xc8
      [    1.262370] LR is at fimd_bind+0x138/0x1a8
      [    1.266450] pc : [<c02fb63c>]    lr : [<c02fb834>]    psr: 20000113
      [    1.266450] sp : ee8d1d28  ip : 00000000  fp : 00000000
      [    1.277906] r10: 00000001  r9 : c09d693c  r8 : c0a2d6a8
      [    1.283114] r7 : 00000034  r6 : 00000001  r5 : ee0bb400  r4 : ee244c10
      [    1.289624] r3 : 00000000  r2 : 00000000  r1 : 00000001  r0 : 00000000
      [    1.296135] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [    1.303426] Control: 10c5387d  Table: 4000404a  DAC: 00000015
      [    1.309154] Process swapper/0 (pid: 1, stack limit = 0xee8d0210)
      [    1.315143] Stack: (0xee8d1d28 to 0xee8d2000)
      [    1.319486] 1d20:                   00000000 c0113d18 ee0bb400 ee0bb400 ee245c30 eebbe210
      [    1.327645] 1d40: ee008a40 ee244c10 ee0bb400 00000001 00000034 c02fb834 00000000 c030a858
      [    1.335804] 1d60: ee244a10 eeb60780 ee008a40 eeb60740 ee0bb400 c03030d0 00000000 00000000
      [    1.343963] 1d80: ee244a10 ee0bb400 00000000 eeb60740 eeb60810 00000000 00000000 c02f6ba4
      [    1.352123] 1da0: ee0bb400 00000000 00000000 c02e0500 ee244a00 c0a04a14 ee0bb400 c02e1de4
      [    1.360282] 1dc0: 00000000 c030a858 00000002 eeb60820 eeb60820 00000002 eeb60780 c03033d4
      [    1.368441] 1de0: c06e9cec 00000000 ee244a10 eeb60780 c0a056f8 c03035fc c0a04b24 c0a04b24
      [    1.376600] 1e00: ee244a10 00000001 c0a049d0 c02f6d34 c0ad462c eeba0790 00000000 ee244a10
      [    1.384759] 1e20: ffffffed c0a049d0 00000000 c03090b0 ee244a10 c0ad462c c0a2d840 c03077a0
      [    1.392919] 1e40: eeb5e880 c024b738 000008db ee244a10 c0a049d0 ee244a44 00000000 c09e71d8
      [    1.401078] 1e60: 000000c6 c0307a6c c0a049d0 00000000 c03079e0 c0305ea8 ee826e5c ee1dc7b4
      [    1.409237] 1e80: c0a049d0 eeb5e880 c0a058a8 c0306e2c c0896204 c0a049d0 c06e9d10 c0a049d0
      [    1.417396] 1ea0: c06e9d10 c0ad4600 00000000 c0308360 00000000 00000003 c06e9d10 c02f6e14
      [    1.425555] 1ec0: 00000000 c0896204 ffffffff 00000000 00000000 00000000 00000000 00000000
      [    1.433714] 1ee0: 00000000 00000000 c02f6d5c c02f6d5c 00000000 eeb5d740 c09e71d8 c0008a30
      [    1.441874] 1f00: ef7fca5e 00000000 00000000 00000066 00000000 ee8d1f28 c003ff1c c02514e8
      [    1.450033] 1f20: 60000113 ffffffff c093906c ef7fca5e 000000c6 c004018c 00000000 c093906c
      [    1.458192] 1f40: c08a9690 c093840c 00000006 00000006 c09eb2ac c09c0d74 00000006 c09c0d54
      [    1.466351] 1f60: c0a3d680 c09745a0 c09d693c 000000c6 00000000 c0974db4 00000006 00000006
      [    1.474510] 1f80: c09745a0 ffffffff 00000000 c0692e00 00000000 00000000 00000000 00000000
      [    1.482669] 1fa0: 00000000 c0692e08 00000000 c000f040 00000000 00000000 00000000 00000000
      [    1.490828] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    1.498988] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
      [    1.507159] [<c02fb63c>] (fimd_wait_for_vblank) from [<c02fb834>] (fimd_bind+0x138/0x1a8)
      [    1.515313] [<c02fb834>] (fimd_bind) from [<c03030d0>] (component_bind_all+0xc4/0x20c)
      [    1.523209] [<c03030d0>] (component_bind_all) from [<c02f6ba4>] (exynos_drm_load+0xa0/0x140)
      [    1.531632] [<c02f6ba4>] (exynos_drm_load) from [<c02e0500>] (drm_dev_register+0xa0/0xf4)
      [    1.539788] [<c02e0500>] (drm_dev_register) from [<c02e1de4>] (drm_platform_init+0x44/0xcc)
      [    1.548121] [<c02e1de4>] (drm_platform_init) from [<c03033d4>] (try_to_bring_up_master.part.1+0xc8/0x104)
      [    1.557668] [<c03033d4>] (try_to_bring_up_master.part.1) from [<c03035fc>] (component_master_add_with_match+0xd0/0x118)
      [    1.568431] [<c03035fc>] (component_master_add_with_match) from [<c02f6d34>] (exynos_drm_platform_probe+0xf0/0x118)
      [    1.578847] [<c02f6d34>] (exynos_drm_platform_probe) from [<c03090b0>] (platform_drv_probe+0x48/0x98)
      [    1.588052] [<c03090b0>] (platform_drv_probe) from [<c03077a0>] (driver_probe_device+0x140/0x380)
      [    1.596902] [<c03077a0>] (driver_probe_device) from [<c0307a6c>] (__driver_attach+0x8c/0x90)
      [    1.605321] [<c0307a6c>] (__driver_attach) from [<c0305ea8>] (bus_for_each_dev+0x54/0x88)
      [    1.613480] [<c0305ea8>] (bus_for_each_dev) from [<c0306e2c>] (bus_add_driver+0xec/0x200)
      [    1.621640] [<c0306e2c>] (bus_add_driver) from [<c0308360>] (driver_register+0x78/0xf4)
      [    1.629625] [<c0308360>] (driver_register) from [<c02f6e14>] (exynos_drm_init+0xb8/0x11c)
      [    1.637785] [<c02f6e14>] (exynos_drm_init) from [<c0008a30>] (do_one_initcall+0xac/0x1ec)
      [    1.645950] [<c0008a30>] (do_one_initcall) from [<c0974db4>] (kernel_init_freeable+0x194/0x268)
      [    1.654626] [<c0974db4>] (kernel_init_freeable) from [<c0692e08>] (kernel_init+0x8/0xe4)
      [    1.662699] [<c0692e08>] (kernel_init) from [<c000f040>] (ret_from_fork+0x14/0x34)
      [    1.670246] Code: eaffffd5 c09df884 e92d40f0 e24dd01c (e5905350)
      [    1.676408] ---[ end trace 804468492f306a6f ]---
      [    1.680948] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      [    1.680948]
      [    1.690035] CPU1: stopping
      [    1.692727] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D         4.0.0-rc1-00062-g7a7cc79-dirty #123
      [    1.702097] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [    1.708192] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14)
      [    1.715908] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8)
      [    1.723108] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4)
      [    1.730485] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c)
      [    1.738036] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74)
      [    1.745498] Exception stack(0xee8fdf98 to 0xee8fdfe0)
      [    1.750533] df80:                                                       00000000 00000000
      [    1.758695] dfa0: ee8fdfe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4
      [    1.766853] dfc0: c0a27a74 c09df940 01000000 ee8fdfe0 c00101c0 c00101c4 60000113 ffffffff
      [    1.775015] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c)
      [    1.782397] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324)
      [    1.790639] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764)
      [    1.797579] CPU0: stopping
      [    1.800272] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G      D         4.0.0-rc1-00062-g7a7cc79-dirty #123
      [    1.809642] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [    1.815730] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14)
      [    1.823450] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8)
      [    1.830653] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4)
      [    1.838030] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c)
      [    1.845581] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74)
      [    1.853043] Exception stack(0xc09ddf60 to 0xc09ddfa8)
      [    1.858081] df60: 00000000 00000000 c09ddfb0 c0021780 c09df938 00000001 ffffffff c0a3d680
      [    1.866239] df80: c09c0dec c09df8d4 c0a27a74 c09df940 01000000 c09ddfa8 c00101c0 c00101c4
      [    1.874396] dfa0: 60000113 ffffffff
      [    1.877872] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c)
      [    1.885251] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324)
      [    1.893499] [<c005e804>] (cpu_startup_entry) from [<c0974bc8>] (start_kernel+0x324/0x37c)
      [    1.901655] [<c0974bc8>] (start_kernel) from [<40008074>] (0x40008074)
      [    1.908161] CPU3: stopping
      [    1.910855] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G      D         4.0.0-rc1-00062-g7a7cc79-dirty #123
      [    1.920225] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [    1.926313] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14)
      [    1.934034] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8)
      [    1.941237] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4)
      [    1.948613] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c)
      [    1.956165] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74)
      [    1.963626] Exception stack(0xee901f98 to 0xee901fe0)
      [    1.968661] 1f80:                                                       00000000 00000000
      [    1.976823] 1fa0: ee901fe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4
      [    1.984982] 1fc0: c0a27a74 c09df940 01000000 ee901fe0 c00101c0 c00101c4 60000113 ffffffff
      [    1.993143] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c)
      [    2.000522] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324)
      [    2.008765] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764)
      [    2.015710] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      Signed-off-by: NHyungwon Hwang <human.hwang@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      cdbfca89
    • I
      drm/exynos: fix typo config name correctly. · 3da6acfc
      Inki Dae 提交于
      This patch fixes DRM_EXYNOS7DECON to DRM_EXYNOS7_DECON.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      3da6acfc
    • C
      drm/exynos: Check for NULL dereference of crtc · 995fdfb9
      Charles Keepax 提交于
      The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
      use of the enabled flag, which means that the code may attempt to call
      win_enable on a NULL crtc. This results in the following oops on
      Arndale:
      
      [    1.673479] Unable to handle kernel NULL pointer dereference at virtual address 00000368
      [    1.681500] pgd = c0004000
      [    1.684154] [00000368] *pgd=00000000
      [    1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      [    1.693012] Modules linked in:
      [    1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
      3.19.0-07545-g57485fa #1907
      [    1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      (....)
      [    2.014803] [<c02f9cfc>] (exynos_plane_destroy) from [<c02e61b4>] (drm_mode_config_cleanup+0x168/0x20c)
      [    2.024178] [<c02e61b4>] (drm_mode_config_cleanup) from [<c02f66fc>] (exynos_drm_load+0xac/0x12c)
      
      This patch adds in a check to ensure exynos_crtc is not NULL before it
      is dereferenced.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      995fdfb9
    • D
      drm/exynos: IS_ERR() vs NULL bug · aed45ab4
      Dan Carpenter 提交于
      of_iomap() doesn't return error pointers, it returns NULL on error.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      aed45ab4
    • A
      drm/exynos: remove unused files · 5fcc3c88
      Andrzej Hajda 提交于
      These files are not used anymore.
      Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      5fcc3c88
  2. 17 3月, 2015 8 次提交
  3. 16 3月, 2015 1 次提交
  4. 12 3月, 2015 4 次提交
  5. 11 3月, 2015 2 次提交
  6. 10 3月, 2015 6 次提交
    • C
      drm/i915: Prevent TLB error on first execution on SNB · 5e4f5189
      Chris Wilson 提交于
      Long ago I found that I was getting sporadic errors when booting SNB,
      with the symptom being that the first batch died with IPEHR != *ACTHD,
      typically caused by the TLB being invalid. These magically disappeared
      if I held the forcewake during the entire ring initialisation sequence.
      (It can probably be shortened to a short critical section, but the whole
      initialisation is full of register writes and so we would be taking and
      releasing forcewake almost continually, and so holding it over the
      entire sequence will probably be a net win!)
      
      Note some of the kernels I encounted the issue already had the deferred
      forcewake release, so it is still relevant.
      
      I know that there have been a few other reports with similar failure
      conditions on SNB, I think such as
      References: https://bugs.freedesktop.org/show_bug.cgi?id=80913
      
      v2: Wrap i915_gem_init_hw() with its own security blanket as we take
      that path following resume and reset.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      5e4f5189
    • M
      drm/i915: Do both mt and gen6 style forcewake reset on ivb probe · 0cd0caad
      Mika Kuoppala 提交于
      commit 05a2fb15 ("drm/i915: Consolidate forcewake code")
      failed to take into account that we have used to reset both
      the gen6 style and the multithreaded style forcewake registers.
      This is due to fact that ivb can use either, depending on how the
      bios has set up the machine.
      
      Mimic the old semantics before we have determined the correct variety
      and reset both before the ecobus probe.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      0cd0caad
    • C
      drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again · 762e4583
      Chris Wilson 提交于
      This fixes a regression from
      
      commit 5ed0bdf2
      Author: Thomas Gleixner <tglx@linutronix.de>
      Date:   Wed Jul 16 21:05:06 2014 +0000
      
          drm: i915: Use nsec based interfaces
      
      that made a negative timeout return immediately rather than the
      previously defined behaviour of waiting indefinitely.
      
      Testcase: igt/gem_wait
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89494Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Kristian Høgsberg <krh@bitplanet.net>
      Cc: stable@vger.kernel.org
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      [Jani: fixed a checkpatch complaint about whitespace.]
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      762e4583
    • D
      drm/i915: use in_interrupt() not in_irq() to check context · 6c51d46f
      Dave Gordon 提交于
      The kernel in_irq() function tests for hard-IRQ context only, so if a
      system is run with the kernel 'threadirqs' option selected, the test in
      intel_check_page_flip() generates lots of warnings, because then it gets
      called in soft-IRQ context.
      
      We can instead use in_interrupt() which allows for either type of
      interrupt, while still detecting and complaining about misuse of the
      page flip code if it is ever called from non-interrupt context.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      6c51d46f
    • D
      drm/mst: fix recursive sleep warning on qlock · cd961bb9
      Daniel Vetter 提交于
      With drm-next, we can get a backtrace from sleeping
      with mutex detection.
      
      this is due to the callback checking the txmsg state taking
      the mutex, which can cause a sleep inside a sleep,
      
      Daniel went over it and was happy we could drop this mutex
      in this case.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      cd961bb9
    • C
      drm: Don't assign fbs for universal cursor support to files · 9a6f5130
      Chris Wilson 提交于
      The internal framebuffers we create to remap legacy cursor ioctls to
      plane operations for the universal plane support shouldn't be linke to
      the file like normal userspace framebuffers. This bug goes back to the
      original universal cursor plane support introduced in
      
      commit 161d0dc1
      Author: Matt Roper <matthew.d.roper@intel.com>
      Date:   Tue Jun 10 08:28:10 2014 -0700
      
          drm: Support legacy cursor ioctls via universal planes when possible (v4)
      
      The isn't too disastrous since fbs are small, we only create one when the
      cursor bo gets changed and ultimately they'll be reaped when the window
      server restarts.
      
      Conceptually we'd want to just pass NULL for file_priv when creating it,
      but the driver needs the file to lookup the underlying buffer object for
      cursor id. Instead let's move the file_priv linking out of
      add_framebuffer_internal() into the addfb ioctl implementation, which is
      the only place it is needed. And also rename the function for a more
      accurate since it only creates the fb, but doesn't add it anywhere.
      
      Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9a6f5130
  7. 05 3月, 2015 9 次提交
  8. 04 3月, 2015 4 次提交
    • I
      drm/i915: gen4: work around hang during hibernation · ab3be73f
      Imre Deak 提交于
      Bjørn reported that his machine hang during hibernation and eventually
      bisected the problem to the following commit:
      
      commit da2bc1b9
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Thu Oct 23 19:23:26 2014 +0300
      
          drm/i915: add poweroff_late handler
      
      The problem seems to be that after the kernel puts the device into D3
      the BIOS still tries to access it, or otherwise assumes that it's in D0.
      This is clearly bogus, since ACPI mandates that devices are put into D3
      by the OSPM if they are not wake-up sources. In the future we want to
      unify more of the driver's runtime and system suspend paths, for example
      by skipping all the system suspend/hibernation hooks if the device is
      runtime suspended already. Accordingly for all other platforms the goal
      is still to properly power down the device during hibernation.
      
      v2:
      - Another GEN4 Lenovo laptop had the same issue, while platforms from
        other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
        to work fine. Based on this apply the workaround on all GEN4 Lenovo
        platforms.
      - add code comment about failing platforms (Ville)
      
      Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.htmlReported-and-bisected-by: NBjørn Mork <bjorn@mork.no>
      Cc: stable@vger.kernel.org # v3.19
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Acked-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ab3be73f
    • C
      drm/i915: Check for driver readyness before handling an underrun interrupt · 54fc7c1c
      Chris Wilson 提交于
      When we takeover from the BIOS and install our interrupt handler, the
      BIOS may have left us a few surprises in the form of spontaneous
      interrupts. (This is especially likely on hardware like 965gm where
      display fifo underruns are continuous and the GMCH cannot filter that
      interrupt souce.) As we enable our IRQ early so that we can use it
      during hardware probing, our interrupt handler must be prepared to
      handle a few sources prior to being fully configured. As such, we need
      to add a simple is-ready check prior to dereferencing our KMS state for
      reporting underruns.
      Reported-by: NRob Clark <rclark@redhat.com>
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [Jani: dropped the extra !]
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      54fc7c1c
    • A
      drm/radeon: fix interlaced modes on DCE8 · 77ae5f4b
      Alex Deucher 提交于
      Need to double the viewport height.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      77ae5f4b
    • T
      drm/radeon: fix DRM_IOCTL_RADEON_CS oops · a28b2a47
      Tommi Rantala 提交于
      Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
      following oops.
      
      Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().
      
      ----------------------------------
      
       #include <stdint.h>
       #include <fcntl.h>
       #include <unistd.h>
       #include <sys/ioctl.h>
       #include <drm/radeon_drm.h>
      
       static const struct drm_radeon_cs cs;
      
       int main(int argc, char **argv)
       {
               return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs);
       }
      
      ----------------------------------
      
      [ttrantal@test2 ~]$ ./main /dev/dri/card0
      [   46.904650] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [   46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240
      [   46.905022] PGD 68f29067 PUD 688b5067 PMD 0
      [   46.905022] Oops: 0002 [#1] SMP
      [   46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
      [   46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
      [   46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000
      [   46.905022] RIP: 0010:[<ffffffff814d6df2>]  [<ffffffff814d6df2>] list_sort+0x42/0x240
      [   46.905022] RSP: 0018:ffff880058e67998  EFLAGS: 00010246
      [   46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [   46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58
      [   46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000
      [   46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410
      [   46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0
      [   46.905022] FS:  00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000
      [   46.905022] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0
      [   46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
      [   46.905022] Stack:
      [   46.905022]  ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000
      [   46.905022]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [   46.905022]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [   46.905022] Call Trace:
      [   46.905022]  [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220
      [   46.905022]  [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960
      [   46.905022]  [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640
      [   46.905022]  [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
      [   46.905022]  [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10
      [   46.905022]  [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80
      [   46.905022]  [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570
      [   46.905022]  [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110
      [   46.905022]  [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0
      [   46.905022]  [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17
      [   46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff
      ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7
      00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
      [   46.905022] RIP  [<ffffffff814d6df2>] list_sort+0x42/0x240
      [   46.905022]  RSP <ffff880058e67998>
      [   46.905022] CR2: 0000000000000000
      [   47.149253] ---[ end trace 09576b4e8b2c20b8 ]---
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NTommi Rantala <tt.rantala@gmail.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      a28b2a47