1. 04 Aug, 2017 4 commits
  2. 31 Jul, 2017 1 commit
  3. 28 Jul, 2017 1 commit
  4. 27 Jul, 2017 1 commit
  5. 24 Jul, 2017 1 commit
    • Arnd Bergmann's avatar
      drm/rockchip: fix Kconfig dependencies · b9670ca2
      Arnd Bergmann authored
      A bug that I had fixed earlier just came back, with CONFIG_EXTCON=m,
      the rockchip drm driver will fail to link:
      
      drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_get_port_lanes':
      cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x30): undefined reference to `extcon_get_state'
      cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x6c): undefined reference to `extcon_get_property'
      drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_check_sink_connection':
      cdn-dp-core.c:(.text.cdn_dp_check_sink_connection+0x80): undefined reference to `extcon_get_state'
      drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_enable':
      cdn-dp-core.c:(.text.cdn_dp_enable+0x748): undefined reference to `extcon_get_property'
      
      The problem is that that the sub-drivers are now all linked into the
      main rockchip drm module, which breaks all the Kconfig dependencies
      that are specified in the options for those sub-drivers.
      
      This clarifies the dependency to ensure that we can only turn on the DP
      driver when EXTCON is reachable. As the 'select' statements can now
      cause additional options to become built-in when they should be
      loadable modules, I'm moving those into the main driver config option.
      The dependency on DRM_ROCKCHIP can be reduced into a single 'if'
      statement here for brevity, but this has no functional effect.
      
      Fixes: b6705157 ("drm/rockchip: add extcon dependency for DP")
      Fixes: 8820b68b ("drm/rockchip: Refactor the component match logic.")
      Link: https://patchwork.kernel.org/patch/9648761/Acked-by: default avatarGuenter Roeck <groeck@chromium.org>
      Tested-by: default avatarJeffy Chen <jeffy.chen@rock-chips.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMark Yao <mark.yao@rock-chips.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170721211214.3386387-1-arnd@arndb.de
      b9670ca2
  6. 21 Jul, 2017 2 commits
  7. 20 Jul, 2017 3 commits
  8. 17 Jul, 2017 1 commit
  9. 14 Jul, 2017 2 commits
    • Boris Brezillon's avatar
      drm/vc4: Fix VBLANK handling in crtc->enable() path · 1ed134e6
      Boris Brezillon authored
      When we are enabling a CRTC, drm_crtc_vblank_get() is called before
      drm_crtc_vblank_on(), which is not supposed to happen (hence the
      WARN_ON() in the code). To solve the problem, we delay the 'update
      display list' operation after the CRTC is actually enabled.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Link: http://patchwork.freedesktop.org/patch/msgid/1498163126-26678-1-git-send-email-boris.brezillon@free-electrons.com
      Fixes: 34c8ea40 ("drm/vc4: Mimic drm_atomic_helper_commit() behavior")
      1ed134e6
    • Chris Wilson's avatar
      dma-buf/fence: Avoid use of uninitialised timestamp · 76250f2b
      Chris Wilson authored
      [  236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8802538683d0)
      [  236.828642] 420000001e7f0000000000000000000000080000000000000000000000000000
      [  236.839543]  i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u
      [  236.850420]                                  ^
      [  236.854123] RIP: 0010:[<ffffffff81396f07>]  [<ffffffff81396f07>] fence_signal+0x17/0xd0
      [  236.861313] RSP: 0018:ffff88024acd7ba0  EFLAGS: 00010282
      [  236.865027] RAX: ffffffff812f6a90 RBX: ffff8802527ca800 RCX: ffff880252cb30e0
      [  236.868801] RDX: ffff88024ac5d918 RSI: ffff880252f780e0 RDI: ffff880253868380
      [  236.872579] RBP: ffff88024acd7bc0 R08: ffff88024acd7be0 R09: 0000000000000000
      [  236.876407] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880253868380
      [  236.880185] R13: ffff8802538684d0 R14: ffff880253868380 R15: ffff88024cd48e00
      [  236.883983] FS:  00007f1646d1a740(0000) GS:ffff88025d000000(0000) knlGS:0000000000000000
      [  236.890959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  236.894702] CR2: ffff880251360318 CR3: 000000024ad21000 CR4: 00000000001406f0
      [  236.898481]  [<ffffffff8130d1ad>] i915_gem_request_retire+0x1cd/0x230
      [  236.902439]  [<ffffffff8130e2b3>] i915_gem_request_alloc+0xa3/0x2f0
      [  236.906435]  [<ffffffff812fb1bd>] i915_gem_do_execbuffer.isra.41+0xb6d/0x18b0
      [  236.910434]  [<ffffffff812fc265>] i915_gem_execbuffer2+0x95/0x1e0
      [  236.914390]  [<ffffffff812ad625>] drm_ioctl+0x1e5/0x460
      [  236.918275]  [<ffffffff8110d4cf>] do_vfs_ioctl+0x8f/0x5c0
      [  236.922168]  [<ffffffff8110da3c>] SyS_ioctl+0x3c/0x70
      [  236.926090]  [<ffffffff814b7a5f>] entry_SYSCALL_64_fastpath+0x17/0x93
      [  236.930045]  [<ffffffffffffffff>] 0xffffffffffffffff
      
      We only set the timestamp before we mark the fence as signaled. It is
      done before to avoid observers having a window in which they may see the
      fence as complete but no timestamp. Having it does incur a potential for
      the timestamp to be written twice, and even for it to be corrupted if
      the u64 write is not atomic. Instead use a new bit to record the
      presence of the timestamp, and teach the readers to wait until it is set
      if the fence is complete. There still remains a race where the timestamp
      for the signaled fence may be shown before the fence is reported as
      signaled, but that's a pre-existing error.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Reported-by: default avatarRafael Antognolli <rafael.antognolli@intel.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170214124001.1930-1-chris@chris-wilson.co.uk
      76250f2b
  10. 10 Jul, 2017 1 commit
  11. 03 Jul, 2017 1 commit
  12. 29 Jun, 2017 1 commit
  13. 27 Jun, 2017 1 commit
  14. 26 Jun, 2017 3 commits
  15. 25 Jun, 2017 6 commits
  16. 24 Jun, 2017 11 commits