1. 29 11月, 2017 1 次提交
  2. 08 11月, 2017 1 次提交
  3. 25 10月, 2017 1 次提交
    • K
      drm: Check mode object lease status in all master ioctl paths [v4] · 7de440db
      Keith Packard 提交于
      Attempts to modify un-leased objects are rejected with an error.
      Information returned about unleased objects is modified to make them
      appear unusable and/or disconnected.
      
      Changes for v2 as suggested by Daniel Vetter <daniel.vetter@ffwll.ch>:
      
       * With the change in the __drm_mode_object_find API to pass the
         file_priv along, we can now centralize most of the lease-based
         access checks in that function.
      
       * A few places skip that API and require in-line checks.
      
      Changes for v3 provided by Dave Airlie <airlied@redhat.com>
      
       * remove support for leasing encoders.
       * add support for leasing planes.
      
      Changes for v4
      
       * Only call drm_lease_held if DRIVER_MODESET.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7de440db
  4. 23 10月, 2017 1 次提交
    • K
      drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v3] · 3064abfa
      Keith Packard 提交于
      These provide crtc-id based functions instead of pipe-number, while
      also offering higher resolution time (ns) and wider frame count (64)
      as required by the Vulkan API.
      
      v2:
      
       * Check for DRIVER_MODESET in new crtc-based vblank ioctls
      
      	Failing to check this will oops the driver.
      
       * Ensure vblank interupt is running in crtc_get_sequence ioctl
      
      	The sequence and timing values are not correct while the
      	interrupt is off, so make sure it's running before asking for
      	them.
      
       * Short-circuit get_sequence if the counter is enabled and accurate
      
      	Steal the idea from the code in wait_vblank to avoid the
      	expense of drm_vblank_get/put
      
       * Return active state of crtc in crtc_get_sequence ioctl
      
      	Might be useful for applications that aren't in charge of
      	modesetting?
      
       * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls
      
      	Daniel Vetter prefers these over the old drm_vblank_put/get
      	APIs.
      
       * Return s64 ns instead of u64 in new sequence event
      Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
      Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      
      v3:
      
       * Removed FIRST_PIXEL_OUT_FLAG
       * Document that the timestamp in the query and event are
         that of the first pixel leaving the display engine for
         the display (using the same wording as the Vulkan spec).
      Suggested-by: NMichel Dänzer <michel@daenzer.net>
      Acked-by: NDave Airlie <airlied@redhat.com>
      
      [airlied: left->leaves (Michel)]
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3064abfa
  5. 21 10月, 2017 2 次提交
    • K
      drm: Reorganize drm_pending_event to support future event types [v2] · bd386e51
      Keith Packard 提交于
      Place drm_event_vblank in a new union that includes that and a bare
      drm_event structure. This will allow new members of that union to be
      added in the future without changing code related to the existing vbl
      event type.
      
      Assignments to the crtc_id field are now done when the event is
      allocated, rather than when delievered. This way, delivery doesn't
      need to have the crtc ID available.
      
      v2:
       * Remove 'dev' argument from create_vblank_event
      
      	It wasn't being used anyways, and if we need it in the future,
      	we can always get it from crtc->dev.
      
       * Check for MODESETTING before looking for crtc in queue_vblank_event
      
      	UMS drivers will oops if we try to get a crtc, so make sure
      	we're modesetting before we try to find a crtc_id to fill into
      	the event.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      (cherry picked from commit dc695b85fde88eca3ef3b03fcd82f15b6bc6e462)
      bd386e51
    • K
      drm: Widen vblank count to 64-bits [v3] · 570e8696
      Keith Packard 提交于
      This modifies the datatypes used by the vblank code to provide 64 bits
      of vblank count.
      
      The driver interfaces have been left using 32 bits of vblank count;
      all of the code necessary to widen that value for the user API was
      already included to handle devices returning fewer than 32-bits.
      
      This will provide the necessary datatypes for the Vulkan API.
      
      v2:
      
       * Re-write wait_vblank ioctl to ABSOLUTE sequence
      
          When an application uses the WAIT_VBLANK ioctl with RELATIVE
          or NEXTONMISS bits set, the target vblank interval is updated
          within the kernel. We need to write that target back to the
          ioctl buffer and update the flags bits so that if the wait is
          interrupted by a signal, when it is re-started, it will target
          precisely the same vblank count as before.
      
       * Leave driver API with 32-bit vblank count
      
      v3:
      
       * Rebase on top of Arnd Bergmann's patch which had
         the switch to ktime_t parts.
      
      [airlied: fix conflict with Ville vblank change].
      Suggested-by: NMichel Dänzer <michel@daenzer.net>
      Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      (cherry picked from commit 2affbc16983e4fc90960bc7f70e7615f4228199b)
      570e8696
  6. 13 10月, 2017 2 次提交
    • A
      drm: vblank: remove drm_timestamp_monotonic parameter · 25e1a798
      Arnd Bergmann 提交于
      There is a risk of overflowing vblank timestamps in 2038 or 2106 if
      someone sets the drm_timestamp_monotonic module parameter to zero.
      
      I found no indication of anyone ever setting the parameter, or
      complaining about the default being wrong, after it was introduced
      as a way to handle backwards-compatibility with linux prior to
      c61eef72 ("drm: add support for monotonic vblank timestamps"),
      so it's probably safer to just remove the parameter completely
      and only allowing the default behavior.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NDaniel Stone <daniels@collabora.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      25e1a798
    • A
      drm: vblank: use ktime_t instead of timeval · 67680d3c
      Arnd Bergmann 提交于
      The drm vblank handling uses 'timeval' to store timestamps in either
      monotonic or wall-clock time base. In either case, it reads the current
      time as a ktime_t in get_drm_timestamp() and converts it from there.
      
      This is a bit suspicious, as users of 'timeval' often suffer from
      the time_t overflow in y2038. I have gone through this code and
      found that it is unlikely to cause problems here:
      
      - The user space ABI does not use time_t or timeval, but uses
        'u32' and 'long' as the types. This means at least that rebuilding
        user programs against a new libc with 64-bit time_t does not
        change the ABI.
      
      - As of commit c61eef72 ("drm: add support for monotonic vblank
        timestamps") in linux-3.8, the monotonic timestamp is the default
        and can only get reverted to wall-clock through a module-parameter.
      
      - With the default monotonic timestamps, there is no problem at all.
      
      - The drm_wait_vblank_ioctl() interface is alway safe on 64-bit
        architectures, on 32-bit it might overflow the 'long' timestamps
        in 2038 with wall-clock timestamps.
      
      - The event handling uses 'u32' seconds, which overflow in 2106
        on both 32-bit and 64-bit machines, when wall-clock timestamps
        are used.
      
      - The effect of overflowing either of the two is only temporary
        (during the overflow, and is likely to keep working again
        afterwards. It is likely the same problem as observing a
        'settimeofday()' call, which was the reason for moving to the
        monotonic timestamps in the first place.
      
      Overall, this seems good enough, so my patch removes the use of
      'timeval' from the vblank handling altogether and uses ktime_t
      consistently, except for the part where we copy the data to user
      space structures in the existing format.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Reviewed-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      67680d3c
  7. 12 10月, 2017 1 次提交
  8. 06 7月, 2017 1 次提交
  9. 29 6月, 2017 1 次提交
  10. 28 6月, 2017 1 次提交
    • D
      drm/vblank: Unexport drm_vblank_cleanup · b4164d66
      Daniel Vetter 提交于
      There's no reason for drivers to call this, and all the ones I've
      removed looked very fishy:
      - Proper quiescenting of the vblank machinery should be done by
        calling drm_crtc_vblank_off(), which is best done by shutting down
        the entire display engine with drm_atomic_helper_shutdown.
      
      - Releasing of allocated memory is done by the core already, it calls
        drm_vblank_cleanup as a fallback.
      
      - drm_vblank_cleanup also has checks for drivers which forget to clean
        up vblank interrupts.
      
      This essentially reverts
      
      commit e77cef9c
      Author: Jerome Glisse <jglisse@redhat.com>
      Date:   Thu Jan 7 15:39:13 2010 +0100
      
          drm: Avoid calling vblank function is vblank wasn't initialized
      
      which was done to fix a bug in radeon code with msi interrupts:
      
      commit 003e69f9
      Author: Jerome Glisse <jglisse@redhat.com>
      Date:   Thu Jan 7 15:39:14 2010 +0100
      
          drm/radeon/kms: Don't try to enable IRQ if we have no handler installed
      
      Afaict from digging around in old code, this was needed to avoid
      blowing up in the ums fallback, and has stopped serving it's purpose
      long ago - if irq init fails, the driver fails to load, and there's
      really no way to blow up anymore.
      
      Long story short, this was most likely a small ums compat/fallback
      hack that became a thing of it's own and got cargo-cult duplicated all
      over the drm codebase for essentially no gain at all.
      
      v2: Mention that for drivers with a ->release callback cleanup is
      handled by drm_dev_fini() (Thierry).
      
      Cc: Thierry Reding <treding@nvidia.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170626161949.25629-2-daniel.vetter@ffwll.ch
      b4164d66
  11. 20 6月, 2017 3 次提交
  12. 01 6月, 2017 2 次提交
  13. 10 5月, 2017 4 次提交
    • D
      drm/vblank: Lock down vblank->hwmode more · 5caa0fea
      Daniel Vetter 提交于
      In the previous patch we've implemented hwmode tracking a la i915 for
      the vblank timestamp calculations. But that was just the basic
      semantics, i915 has some nice sanity checks to make sure we keep
      getting this right. Move them over too.
      
      v2:
      - WARN_ON_ONCE to avoid excessive spam (Ville)
      - Really only WARN on atomic drivers.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-5-daniel.vetter@ffwll.ch
      5caa0fea
    • D
      drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos · 1bf6ad62
      Daniel Vetter 提交于
      If we restrict this helper to only kms drivers (which is the case) we
      can look up the correct mode easily ourselves. But it's a bit tricky:
      
      - All legacy drivers look at crtc->hwmode. But that is updated already
        at the beginning of the modeset helper, which means when we disable
        a pipe. Hence the final timestamps might be a bit off. But since
        this is an existing bug I'm not going to change it, but just try to
        be bug-for-bug compatible with the current code. This only applies
        to radeon&amdgpu.
      
      - i915 tries to get it perfect by updating crtc->hwmode when the pipe
        is off (i.e. vblank->enabled = false).
      
      - All other atomic drivers look at crtc->state->adjusted_mode. Those
        that look at state->requested_mode simply don't adjust their mode,
        so it's the same. That has two problems: Accessing crtc->state from
        interrupt handling code is unsafe, and it's updated before we shut
        down the pipe. For nonblocking modesets it's even worse.
      
      For atomic drivers try to implement what i915 does. To do that we add
      a new hwmode field to the vblank structure, and update it from
      drm_calc_timestamping_constants(). For atomic drivers that's called
      from the right spot by the helper library already, so all fine. But
      for safety let's enforce that.
      
      For legacy driver this function is only called at the end (oh the
      fun), which is broken, so again let's not bother and just stay
      bug-for-bug compatible.
      
      The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
      directly to implement ->get_vblank_timestamp in every driver, deleting
      a lot of code.
      
      v2: Completely new approach, trying to mimick the i915 solution.
      
      v3: Fixup kerneldoc.
      
      v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
      currently unconditionally call this. Recomputing the same stuff should
      be harmless.
      
      v5: Fix typos and move misplaced hunks to the right patches (Neil).
      
      v6: Undo hunk movement (kbuild).
      
      Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
      1bf6ad62
    • D
      drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp · 3fcdcb27
      Daniel Vetter 提交于
      It's overkill to have a flag parameter which is essentially used just
      as a boolean. This takes care of core + adjusting drivers.
      
      Adjusting the scanout position callback is a bit harder, since radeon
      also supplies it's own driver-private flags in there.
      
      v2: Fixup misplaced hunks (Neil).
      
      v3: kbuild says v1 was better ...
      
      Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch
      3fcdcb27
    • D
      drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool · d673c02c
      Daniel Vetter 提交于
      There's really no reason for anything more:
      - Calling this while the crtc vblank stuff isn't set up is a driver
        bug. Those places alrready DRM_ERROR.
      - Calling this when the crtc is off is either a driver bug (calling
        drm_crtc_handle_vblank at the wrong time) or a core bug (for
        anything else). Again, we DRM_ERROR.
      - EINVAL is checked at higher levels already, and if we'd use struct
        drm_crtc * instead of (dev, pipe) it would be real obvious that
        those are again core bugs.
      
      The only valid failure mode is crap hardware that couldn't sample a
      useful timestamp, to ask the core to just grab a not-so-accurate
      timestamp. Bool is perfectly fine for that.
      
      v2: Also fix up the one caller, I lost that in the shuffling (Jani).
      
      v3: Fixup commit message (Neil).
      
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch
      d673c02c
  14. 05 4月, 2017 1 次提交
  15. 30 3月, 2017 1 次提交
  16. 29 3月, 2017 5 次提交
  17. 26 3月, 2017 1 次提交
  18. 16 3月, 2017 2 次提交
    • C
      drm: Skip the waitqueue setup for vblank queries · 82c8e025
      Chris Wilson 提交于
      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: NChris 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: NMichel Dänzer <michel@daenzer.net>
      Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-2-chris@chris-wilson.co.uk
      82c8e025
    • C
      drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) · 608b2050
      Chris Wilson 提交于
      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: NChris 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: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.uk
      608b2050
  19. 14 3月, 2017 1 次提交
  20. 08 2月, 2017 2 次提交
  21. 26 1月, 2017 1 次提交
  22. 25 1月, 2017 1 次提交
  23. 30 12月, 2016 1 次提交
  24. 18 12月, 2016 1 次提交
  25. 16 11月, 2016 2 次提交