1. 06 8月, 2015 1 次提交
    • D
      drm/i915: Allow parsing of variable size child device entries from VBT · 047fe6e6
      David Weinehall 提交于
      VBT version 196 increased the size of common_child_dev_config. The parser
      code assumed that the size of this structure would not change.
      
      The modified code now copies the amount needed based on the VBT version,
      and emits a debug message if the VBT version is unknown (too new);
      since the struct config block won't shrink in newer versions it should
      be harmless to copy the maximum known size in such cases, so that's
      what we do, but emitting the warning is probably sensible anyway.
      
      In the longer run it might make sense to modify the parser code to
      use a version/feature mapping, rather than hardcoding things like this,
      but for now the variants are fairly managable.
      
      This fixes a regression introduced in
      
      commit 90e4f159
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Wed Mar 25 18:45:58 2015 +0200
      
          drm/i915: Fix the VBT child device parsing for BSW
      
      since we're hitting a DRM_ERROR on older platforms with this.
      
      v2: Stricter size checks
      Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      [danvet: Fixup format string.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      047fe6e6
  2. 30 7月, 2015 2 次提交
    • C
      drm/i915: Declare the swizzling unknown for L-shaped configurations · 5eb3e5a5
      Chris Wilson 提交于
      The old style of memory interleaving swizzled upto the end of the
      first even bank of memory, and then used the remainder as unswizzled on
      the unpaired bank - i.e. swizzling is not constant for all memory. This
      causes problems when we try to migrate memory and so the kernel prevents
      migration at all when we detect L-shaped inconsistent swizzling.
      However, this issue also extends to userspace who try to manually detile
      into memory as the swizzling for an individual page is unknown (it
      depends on its physical address only known to the kernel), userspace
      cannot correctly swizzle.
      
      Note that this is a new attempt for the previously merged one,
      reverted in
      
      commit d82c0ba6
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Jul 14 12:29:27 2015 +0200
      
          Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"
      
      This is cc: stable since we need it to fix up troubles with wc cpu
      mmaps that userspace recently started to use widely.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [danvet: Add note about previous (failed attempt).]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5eb3e5a5
    • C
      drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt · d0e30adc
      Chris Wilson 提交于
      If the device does not support the aliasing ppgtt, we must translate
      user bind requests (PIN_USER) from LOCAL_BIND to a GLOBAL_BIND. However,
      since this is device specific we cannot do this conveniently in the
      upper layers and so must manage the vma->bound flags in the backend.
      
      Partial revert of commit 75d04a37 [4.2-rc1]
      Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Date:   Tue Apr 28 17:56:17 2015 +0300
      
          drm/i915/gtt: Allocate va range only if vma is not bound
      
      Note this was spotted by Daniel originally, but we dropped the ball in
      getting the fix in before the bug going wild. Sorry all.
      
      Reported-by: Vincent Legoll vincent.legoll@gmail.com
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91133
      References: https://bugs.freedesktop.org/show_bug.cgi?id=90224Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d0e30adc
  3. 29 7月, 2015 1 次提交
  4. 24 7月, 2015 3 次提交
  5. 23 7月, 2015 4 次提交
  6. 22 7月, 2015 1 次提交
  7. 21 7月, 2015 2 次提交
  8. 17 7月, 2015 15 次提交
  9. 15 7月, 2015 7 次提交
  10. 14 7月, 2015 4 次提交
    • M
      drm/i915: Do not call intel_crtc_disable if the crtc is already disabled. · ccfb8b2e
      Maarten Lankhorst 提交于
      When resuming with dpms off, the following warn can happen:
      
      [  118.334082] ------------[ cut here ]------------
      [  118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]()
      [  118.334106] WARN_ON(!crtc->state->enable)
      [  118.334137] Modules linked in: i915
      [  118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148
      [  118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
      [  118.334144] Workqueue: events_unbound async_run_entry_fn
      [  118.334147]  ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001
      [  118.334149]  ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8
      [  118.334151]  ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668
      [  118.334151] Call Trace:
      [  118.334155]  [<ffffffff817aa62a>] dump_stack+0x4f/0x7b
      [  118.334157]  [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0
      [  118.334158]  [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50
      [  118.334173]  [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915]
      [  118.334188]  [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915]
      [  118.334191]  [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80
      [  118.334205]  [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915]
      [  118.334219]  [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915]
      [  118.334232]  [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915]
      [  118.334246]  [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915]
      [  118.334248]  [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90
      [  118.334255]  [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915]
      [  118.334262]  [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915]
      [  118.334263]  [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0
      [  118.334266]  [<ffffffff81467550>] dpm_run_callback+0x70/0x420
      [  118.334267]  [<ffffffff81467cbd>] device_resume+0x9d/0x1c0
      [  118.334269]  [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60
      [  118.334270]  [<ffffffff81467dfc>] async_resume+0x1c/0x50
      [  118.334271]  [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0
      [  118.334273]  [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0
      [  118.334275]  [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0
      [  118.334276]  [<ffffffff8109daf9>] worker_thread+0x49/0x450
      [  118.334278]  [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0
      [  118.334280]  [<ffffffff810a3cb9>] kthread+0xf9/0x110
      [  118.334282]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
      [  118.334284]  [<ffffffff817b414f>] ret_from_fork+0x3f/0x70
      [  118.334286]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
      [  118.334287] ---[ end trace 01f2cf6371b82d7a ]---
      
      This warn is harmless, and can be fixed by not calling intel_crtc_disable when
      the crtc is already disabled.
      Reported-and-Tested-by: NJörg Otte <jrg.otte@gmail.com>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ccfb8b2e
    • D
      Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations" · d82c0ba6
      Daniel Vetter 提交于
      This reverts commit 19ee835c.
      
      It breaks existing old userspace which doesn't handle UNKNOWN
      swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably
      still is on some other platforms, but it still pretty clearly broke
      the testers machine. If we want this we need to extend the ioctl with
      new paramters that only new userspace looks at.
      
      Cc: Harald Arnesen <harald@skogtun.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reported-by: NHarald Arnesen <harald@skogtun.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      d82c0ba6
    • T
      drm/i915: Forward all core DRM ioctls to core compat handling · ac7e7ab1
      Tvrtko Ursulin 提交于
      Previously only core DRM ioctls under the DRM_COMMAND_BASE were being
      forwarded, but the drm.h header suggests (and reality confirms) ones
      after (and including) DRM_COMMAND_END should be forwarded as well.
      
      We need this to correctly forward the compat ioctl for the botched-up
      addfb2.1 extension.
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: stable@vger.kernel.org # 4.1+
      [danvet: Explain why this is suddenly needed and add cc: stable.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ac7e7ab1
    • D
      drm/i915: fix oops in primary_check_plane · bbf47020
      Daniel Vetter 提交于
      On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote:
      > On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <jrg.otte@gmail.com> wrote:
      > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
      > > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb
      >
      > Ugh. Please enable KALLSYMS to get sane symbols.
      >
      > But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
      > so it's pretty clearly just that change frm
      >
      > -       if (intel_crtc->active) {
      > +       if (crtc_state->base.active) {
      >
      > and "crtc_state" is NULL.
      >
      > And the code very much knows that crtc_state can be NULL, since it's
      > initialized with
      >
      >         crtc_state = state->base.state ?
      >                 intel_atomic_get_crtc_state(state->base.state,
      > intel_crtc) : NULL;
      >
      > Tssk. Daniel? Should I just revert that commit dec4f799
      > ("drm/i915: Use crtc_state->active in primary check_plane func") for
      > now, or is there a better fix? Like just checking crtc_state for NULL?
      
      Indeed embarrassing. I've missed that we still have 1 caller left that's
      using the transitional helpers, and those don't fill out
      plane_state->state backpointers to the global atomic update since there is
      no global atomic update for transitional helpers. Below diff should fix
      this - we need to preferentially check crts_state->active and if that's
      not set intel_crtc->active should yield the right result for the one
      remaining caller (it's in the crtc_disable paths).
      
      This fixes a regression introduced in
      
      commit dec4f799
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Jul 7 11:15:47 2015 +0200
      
          drm/i915: Use crtc_state->active in primary check_plane func
      
      which was quickly reverted in
      
      commit 01e2d062
      Author: Linus Torvalds <torvalds@linux-foundation.org>
      Date:   Sun Jul 12 15:00:20 2015 -0700
      
          Revert "drm/i915: Use crtc_state->active in primary check_plane func"
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jörg Otte <jrg.otte@gmail.com>
      Reported-and-tested-by: NJörg Otte <jrg.otte@gmail.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      bbf47020