1. 30 Oct, 2018 11 commits
  2. 29 Oct, 2018 13 commits
  3. 26 Oct, 2018 3 commits
    • Clint Taylor's avatar
      drm/i915/hdmi: Detect HDMI 2.0 monitors using multiple EDID capabilities · 47164e0b
      Clint Taylor authored
      HDMI 2.0 monitors may not support SCDC and still be able to accept VICs
      above 63. Use multiple EDID capbilities to determine if the SINK is
      actually an HDMI 2.0 device. The QD980B HDMI 2.0 Analyzer generates unique
      EDIDs during CTS tests that don't contain a HDMI Forum VSDB if the block is
      not used during the test. The current HDMI AVI infoframe code only uses the
      SCDC supported information in the HDMI Forum VSDB to determine if the sink
      is HDMI 2.0. This patch adds a check for YCbCr420 present in the EDID
      supported formats as well as the existing SCDC supported check.
      
      HDMI 2.0 CTS HF1-51 test fails on the QD980B.
      
      V2: Make check for display_info->color formats == YCbCR420 and SCDC
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107894
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: default avatarClint Taylor <clinton.a.taylor@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1540415073-5102-1-git-send-email-clinton.a.taylor@intel.com
      47164e0b
    • Chris Wilson's avatar
      dma-buf: Update reservation shared_count after adding the new fence · a590d0fd
      Chris Wilson authored
      We need to serialise the addition of a new fence into the shared list
      such that the fence is visible before we claim it is there. Otherwise a
      concurrent reader of the shared fence list will see an uninitialised
      fence slot before it is set.
      
        <4> [109.613162] general protection fault: 0000 [#1] PREEMPT SMP PTI
        <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G     U            4.19.0-rc8-CI-CI_DRM_5035+ #1
        <4> [109.613189] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
        <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915]
        <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b 3e e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00
        0f 84 bb 00 00 00 31 c0 <49> 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00
        <4> [109.613283] RSP: 0018:ffffc9000044bcf8 EFLAGS: 00010246
        <4> [109.613292] RAX: 0000000000000000 RBX: ffffc9000044bdc0 RCX: 0000000000000001
        <4> [109.613302] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffffffff822474a0
        <4> [109.613311] RBP: ffffc9000044bd28 R08: ffff88021e158680 R09: 0000000000000001
        <4> [109.613321] R10: 0000000000000040 R11: 0000000000000000 R12: ffff88021e1641b8
        <4> [109.613331] R13: 0000000000000003 R14: ffff88021e1641b0 R15: 6b6b6b6b6b6b6b6b
        <4> [109.613341] FS:  00007f9c9fc84980(0000) GS:ffff880227a40000(0000) knlGS:0000000000000000
        <4> [109.613352] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        <4> [109.613360] CR2: 00007f9c9fcb8000 CR3: 00000002247d4005 CR4: 00000000000606e0
      
      Fixes: 27836b64 ("dma-buf: remove shared fence staging in reservation object")
      Testcase: igt/gem_busy/close-race
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Junwei Zhang <Jerry.Zhang@amd.com>
      Cc: Huang Rui <ray.huang@amd.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181026080302.11507-1-chris@chris-wilson.co.uk
      a590d0fd
    • Chunming Zhou's avatar
      drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock · 4fb2c933
      Chunming Zhou authored
      drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389 but uses GFP_KERNEL
      
        Find functions that refer to GFP_KERNEL but are called with locks held.
      
      Generated by: scripts/coccinelle/locks/call_kern.cocci
      
      v2:
      syncobj->timeline still needs protect.
      
      v3:
      use a global signaled fence instead of re-allocation.
      
      v4:
      Don't need moving lock.
      Don't expose func.
      
      v5:
      rename func and directly return.
      
      Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with
      lock debug kernel options enabled.
      Signed-off-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: Christian König <easy2remember.chk@googlemail.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Julia Lawall <julia.lawall@lip6.fr>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/258623/
      4fb2c933
  4. 25 Oct, 2018 10 commits
  5. 24 Oct, 2018 3 commits