1. 20 8月, 2016 2 次提交
  2. 12 7月, 2016 1 次提交
    • M
      drm/vc4: Implement precise vblank timestamping. · 1bf59f1d
      Mario Kleiner 提交于
      Precise vblank timestamping is implemented via the
      usual scanout position based method. On VC4 the
      pixelvalves PV do not have a scanout position
      register. Only the hardware video scaler HVS has a
      similar register which describes which scanline for
      the output is currently composited and stored in the
      HVS fifo for later consumption by the PV.
      
      This causes a problem in that the HVS runs at a much
      faster clock (system clock / audio gate) than the PV
      which runs at video mode dot clock, so the unless the
      fifo between HVS and PV is full, the HVS will progress
      faster in its observable read line position than video
      scan rate, so the HVS position reading can't be directly
      translated into a scanout position for timestamp correction.
      
      Additionally when the PV is in vblank, it doesn't consume
      from the fifo, so the fifo gets full very quickly and then
      the HVS stops compositing until the PV enters active scanout
      and starts consuming scanlines from the fifo again, making
      new space for the HVS to composite.
      
      Therefore a simple translation of HVS read position into
      elapsed time since (or to) start of active scanout does
      not work, but for the most interesting cases we can still
      get useful and sufficiently accurate results:
      
      1. The PV enters active scanout of a new frame with the
         fifo of the HVS completely full, and the HVS can refill
         any fifo line which gets consumed and thereby freed up by
         the PV during active scanout very quickly. Therefore the
         PV and HVS work effectively in lock-step during active
         scanout with the fifo never having more than 1 scanline
         freed up by the PV before it gets refilled. The PV's
         real scanout position is therefore trailing the HVS
         compositing position as scanoutpos = hvspos - fifosize
         and we can get the true scanoutpos as HVS readpos minus
         fifo size, so precise timestamping works while in active
         scanout, except for the last few scanlines of the frame,
         when the HVS reaches end of frame, stops compositing and
         the PV catches up and drains the fifo. This special case
         would only introduce minor errors though.
      
      2. If we are in vblank, then we can only guess something
         reasonable. If called from vblank irq, we assume the irq is
         usually dispatched with minimum delay, so we can take a
         timestamp taken at entry into the vblank irq handler as a
         baseline and then add a full vblank duration until the
         guessed start of active scanout. As irq dispatch is usually
         pretty low latency this works with relatively low jitter and
         good results.
      
         If we aren't called from vblank then we could be anywhere
         within the vblank interval, so we return a neutral result,
         simply the current system timestamp, and hope for the best.
      
      Measurement shows the generated timestamps to be rather precise,
      and at least never off more than 1 vblank duration worst-case.
      
      Limitations: Doesn't work well yet for interlaced video modes,
                   therefore disabled in interlaced mode for now.
      
      v2: Use the DISPBASE registers to determine the FIFO size (changes
          by anholt)
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> (v2)
      1bf59f1d
  3. 07 6月, 2016 2 次提交
    • M
      drm/core: Change declaration for gamma_set. · 7ea77283
      Maarten Lankhorst 提交于
      Change return value to int to propagate errors from gamma_set,
      and remove start parameter. Updates always use the full size,
      and some drivers even ignore the start parameter altogether.
      
      This is needed for atomic drivers, where an atomic commit can
      fail with -EINTR or -ENOMEM and should be restarted. This is already
      and issue for drm_atomic_helper_legacy_set_gamma, which this patch
      fixes up.
      
      Changes since v1:
      - Fix compiler warning. (Emil)
      - Fix commit message (Daniel)
      
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
      Cc: Mathieu Larouche <mathieu.larouche@matrox.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      [danvet: Improve commit message a bit more, mention that this fixes
      the helper.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/742944bc-9f41-1acb-df4f-0fd4c8a10168@linux.intel.com
      7ea77283
    • M
      drm/vc4: Make pageflip completion handling more robust. · 56d1fe09
      Mario Kleiner 提交于
      Protect both the setup of the pageflip event and the
      latching of the new requested displaylist head pointer
      by the event lock, so we can't get into a situation
      where vc4_atomic_flush latches the new display list via
      HVS_WRITE, then immediately gets preempted before queueing
      the pageflip event, then the page-flip completes in hw and
      the vc4_crtc_handle_page_flip() runs and no-ops due to
      lack of a pending pageflip event, then vc4_atomic_flush
      continues and only then queues the pageflip event - after
      the page flip handling already no-oped. This would cause
      flip completion handling only at the next vblank - one
      frame too late.
      
      In vc4_crtc_handle_page_flip() check the actual DL head
      pointer in SCALER_DISPLACTX against the requested pointer
      for page flip to make sure that the flip actually really
      completed in the current vblank and doesn't get deferred
      to the next one because the DL head pointer was written
      a bit too late into SCALER_DISPLISTX, after start of
      vblank, and missed the boat. This avoids handling a
      pageflip completion too early - one frame too early.
      
      According to Eric, DL head pointer updates which were
      written into the HVS DISPLISTX reg get committed to hardware
      at the last pixel of active scanout. Our vblank interrupt
      handler, as triggered by PV_INT_VFP_START irq, gets to run
      earliest at the first pixel of HBLANK at the end of the
      last scanline of active scanout, ie. vblank irq handling
      runs at least 1 pixel duration after a potential pageflip
      completion happened in hardware.
      
      This ordering of events in the hardware, together with the
      lock protection and SCALER_DISPLACTX sampling of this patch,
      guarantees that pageflip completion handling only runs at
      exactly the vblank irq of actual pageflip completion in all
      cases.
      
      Background info from Eric about the relative timing of
      HVS, PV's and trigger points for interrupts, DL updates:
      
      https://lists.freedesktop.org/archives/dri-devel/2016-May/107510.html
      
      Tested on RPi 2B with hardware timing measurement equipment
      and shown to no longer complete flips too early or too late.
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: NEric Anholt <eric@anholt.net>
      56d1fe09
  4. 02 6月, 2016 1 次提交
  5. 01 6月, 2016 1 次提交
  6. 17 5月, 2016 1 次提交
  7. 03 5月, 2016 1 次提交
    • E
      drm/vc4: Add support for gamma ramps. · e582b6c7
      Eric Anholt 提交于
      We could possibly save a bit of power by not requesting gamma
      conversion when the ramp happens to be 1:1, but at least if all the
      CRTCs are off the SRAM will be disabled.
      
      This should fix brightness sliders in a lot of fullscreen games.
      Signed-off-by: NEric Anholt <eric@anholt.net>
      e582b6c7
  8. 27 2月, 2016 4 次提交
  9. 17 2月, 2016 2 次提交
  10. 08 2月, 2016 1 次提交
  11. 06 1月, 2016 1 次提交
  12. 11 12月, 2015 1 次提交
    • V
      drm: Pass 'name' to drm_crtc_init_with_planes() · f9882876
      Ville Syrjälä 提交于
      Done with coccinelle for the most part. However, it thinks '...' is
      part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
      in its place and got rid of it with sed afterwards.
      
      I didn't convert drm_crtc_init() since passing the varargs through
      would mean either cpp macros or va_list, and I figured we don't
      care about these legacy functions enough to warrant the extra pain.
      
      @@
      identifier dev, crtc, primary, cursor, funcs;
      @@
       int drm_crtc_init_with_planes(struct drm_device *dev,
                                     struct drm_crtc *crtc,
                                     struct drm_plane *primary, struct drm_plane *cursor,
                                     const struct drm_crtc_funcs *funcs
      +                              ,const char *name, int DOTDOTDOT
                                     )
      { ... }
      
      @@
      identifier dev, crtc, primary, cursor, funcs;
      @@
       int drm_crtc_init_with_planes(struct drm_device *dev,
                                     struct drm_crtc *crtc,
                                     struct drm_plane *primary, struct drm_plane *cursor,
                                     const struct drm_crtc_funcs *funcs
      +                              ,const char *name, int DOTDOTDOT
                                     );
      
      @@
      expression E1, E2, E3, E4, E5;
      @@
       drm_crtc_init_with_planes(E1, E2, E3, E4, E5
      +                          ,NULL
                                 )
      
      v2: Split crtc and plane changes apart
          Pass NULL for no-name instead of ""
          Leave drm_crtc_init() alone
      v3: Add ', or NULL...' to @name kernel doc (Jani)
          Annotate the function with __printf() attribute (Jani)
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1449670771-2751-1-git-send-email-ville.syrjala@linux.intel.com
      f9882876
  13. 08 12月, 2015 1 次提交
  14. 18 11月, 2015 3 次提交
  15. 21 10月, 2015 1 次提交
    • E
      drm/vc4: Add KMS support for Raspberry Pi. · c8b75bca
      Eric Anholt 提交于
      This is enough for fbcon and bringing up X using
      xf86-video-modesetting.  It doesn't support the 3D accelerator or
      power management yet.
      
      v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
          ordering instead of using the .load hook.  Structure registration
          more like tegra's, but still using the typical "component" code.
          Drop no-op hooks for atomic_begin and mode_fixup() now that
          they're optional.  Drop sentinel in Makefile.  Fix minor style
          nits I noticed on another reread.
      
      v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
          of having a fixed video mode.  Use exynos-style component driver
          matching instead of devicetree nodes to list the component driver
          instances.  Rename compatibility strings to say bcm2835, and
          distinguish pv0/1/2.  Clean up some h/vsync code, and add in
          interlaced mode setup.  Fix up probe/bind error paths.  Use
          bitops.h macros for vc4_regs.h
      
      v4: Include i2c.h, allow building under COMPILE_TEST, drop msleep now
          that other bugs have been fixed, add timeouts to cpu_relax()
          loops, rename hpd-gpio to hpd-gpios.
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c8b75bca