1. 16 Mar, 2017 3 commits
    • Boris Brezillon's avatar
      drm/atmel-hlcdc: Fix suspend/resume implementation · 99ed4d7e
      Boris Brezillon authored
      The current suspend resume implementation is assuming register values are
      kept when entering suspend, which is no longer the case with the
      suspend-to-RAM on the sama5d2.
      
      While at it, switch to the generic infrastructure to enter suspend mode
      (drm_atomic_helper_suspend/resume()).
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: default avatarSylvain Rochet <sylvain.rochet@finsecur.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1488371461-22243-1-git-send-email-boris.brezillon@free-electrons.com
      99ed4d7e
    • Chris Wilson's avatar
      drm: Skip the waitqueue setup for vblank queries · 82c8e025
      Chris Wilson authored
      Avoid adding to the waitqueue and reprobing the current vblank if the
      caller is only querying the current vblank sequence and timestamp, where
      we know that the wait would return immediately.
      
      v2: Add CRTC identifier to debug messages
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Michel Dänzer <michel@daenzer.net>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Dave Airlie <airlied@redhat.com>,
      Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarMichel Dänzer <michel@daenzer.net>
      Reviewed-and-tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-2-chris@chris-wilson.co.uk
      82c8e025
    • Chris Wilson's avatar
      drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) · 608b2050
      Chris Wilson authored
      On vblank instant-off systems, we can get into a situation where the cost
      of enabling and disabling the vblank IRQ around a drmWaitVblank query
      dominates. And with the advent of even deeper hardware sleep state,
      touching registers becomes ever more expensive.  However, we know that if
      the user wants the current vblank counter, they are also very likely to
      immediately queue a vblank wait and so we can keep the interrupt around
      and only turn it off if we have no further vblank requests queued within
      the interrupt interval.
      
      After vblank event delivery, this patch adds a shadow of one vblank where
      the interrupt is kept alive for the user to query and queue another vblank
      event. Similarly, if the user is using blocking drmWaitVblanks, the
      interrupt will be disabled on the IRQ following the wait completion.
      However, if the user is simply querying the current vblank counter and
      timestamp, the interrupt will be disabled after every IRQ and the user
      will enabled it again on the first query following the IRQ.
      
      v2: Mario Kleiner -
      After testing this, one more thing that would make sense is to move
      the disable block at the end of drm_handle_vblank() instead of at the
      top.
      
      Turns out that if high precision timestaming is disabled or doesn't
      work for some reason (as can be simulated by echo 0 >
      /sys/module/drm/parameters/timestamp_precision_usec), then with your
      delayed disable code at its current place, the vblank counter won't
      increment anymore at all for instant queries, ie. with your other
      "instant query" patches. Clients which repeatedly query the counter
      and wait for it to progress will simply hang, spinning in an endless
      query loop. There's that comment in vblank_disable_and_save:
      
      "* Skip this step if there isn't any high precision timestamp
       * available. In that case we can't account for this and just
       * hope for the best.
       */
      
      With the disable happening after leading edge of vblank (== hw counter
      increment already happened) but before the vblank counter/timestamp
      handling in drm_handle_vblank, that step is needed to keep the counter
      progressing, so skipping it is bad.
      
      Now without high precision timestamping support, a kms driver must not
      set dev->vblank_disable_immediate = true, as this would cause problems
      for clients, so this shouldn't matter, but it would be good to still
      make this robust against a future kms driver which might have
      unreliable high precision timestamping, e.g., high precision
      timestamping that intermittently doesn't work.
      
      v3: Patch before coffee needs extra coffee.
      
      Testcase: igt/kms_vblank
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Michel Dänzer <michel@daenzer.net>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Dave Airlie <airlied@redhat.com>,
      Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.uk
      608b2050
  2. 14 Mar, 2017 13 commits
  3. 13 Mar, 2017 3 commits
  4. 11 Mar, 2017 1 commit
  5. 10 Mar, 2017 10 commits
  6. 09 Mar, 2017 10 commits