1. 22 7月, 2015 1 次提交
  2. 07 7月, 2015 1 次提交
  3. 04 7月, 2015 1 次提交
  4. 12 6月, 2015 1 次提交
  5. 26 5月, 2015 3 次提交
  6. 22 5月, 2015 6 次提交
  7. 12 5月, 2015 1 次提交
  8. 08 5月, 2015 2 次提交
  9. 07 5月, 2015 1 次提交
  10. 14 4月, 2015 1 次提交
    • M
      drm: Make integer overflow checking cover universal cursor updates (v2) · 3968be94
      Matt Roper 提交于
      Our legacy SetPlane updates perform integer overflow checking on a
      plane's destination rectangle in drm_mode_setplane(), and atomic updates
      handled as part of a drm_atomic_state transaction do the same checking
      in drm_atomic_plane_check().  However legacy cursor updates that get
      routed through universal plane interfaces may bypass this overflow
      checking if the driver's .update_plane is serviced by the transitional
      plane helpers rather than the full atomic plane helpers.
      
      Move the check for destination rectangle integer overflow from the
      drm_mode_setplane() to __setplane_internal() so that it also covers
      cursor operations.
      
      This fixes an issue first noticed with i915 commit:
      
              commit ff42e093
              Author: Daniel Vetter <daniel.vetter@ffwll.ch>
              Date:   Mon Mar 2 16:35:20 2015 +0100
      
                  Revert "drm/i915: Switch planes from transitional helpers to full
                  atomic helpers"
      
      The above revert switched us from full atomic helpers back to the
      transitional helpers, and in doing so we lost the overflow checking here
      for universal cursor updates.  Even though such extreme cursor positions
      are unlikely to actually happen in the wild, we still don't want there
      to be a change of behavior when drivers switch from transitional helpers
      to full helpers.
      
      v2: Move check from setplane ioctl to setplane_internal rather than
          adding an additional copy of the checks to the transitional plane
          helpers.  (Daniel)
      
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Testcase: igt/kms_cursor_crc
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84269Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3968be94
  11. 10 4月, 2015 1 次提交
  12. 08 4月, 2015 1 次提交
  13. 02 4月, 2015 1 次提交
  14. 24 3月, 2015 1 次提交
    • D
      drm: Fixup racy refcounting in plane_force_disable · 8218c3f4
      Daniel Vetter 提交于
      Originally it was impossible to be dropping the last refcount in this
      function since there was always one around still from the idr. But in
      
      commit 83f45fc3
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Aug 6 09:10:18 2014 +0200
      
          drm: Don't grab an fb reference for the idr
      
      we've switched to weak references, broke that assumption but forgot to
      fix it up.
      
      Since we still force-disable planes it's only possible to hit this
      when racing multiple rmfb with fbdev restoring or similar evil things.
      As long as userspace is nice it's impossible to hit the BUG_ON.
      
      But the BUG_ON would most likely be hit from fbdev code, which usually
      invovles the console_lock besides all modeset locks. So very likely
      we'd never get the bug reports if this was hit in the wild, hence
      better be safe than sorry and backport.
      
      Spotted by Matt Roper while reviewing other patches.
      
      [airlied: pull this back into 4.0 - the oops happens there]
      
      Cc: stable@vger.kernel.org
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      8218c3f4
  15. 17 3月, 2015 1 次提交
  16. 10 3月, 2015 5 次提交
    • L
      drm: Check in setcrtc if the primary plane supports the fb pixel format · 7eb5f302
      Laurent Pinchart 提交于
      Drivers implementing the universal planes API report the list of
      supported pixel formats for the primary plane. Make sure the fb passed
      to the setcrtc ioctl is compatible.
      
      Drivers not implementing the universal planes API will have no format
      reported for the primary plane, skip the check in that case.
      Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7eb5f302
    • L
      drm: Share plane pixel format check code between legacy and atomic · ead8610d
      Laurent Pinchart 提交于
      Both the legacy and atomic helpers need to check whether a plane
      supports a given pixel format. The code is currently duplicated, share
      it.
      Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      [danvet: Slightly extend the docbook.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ead8610d
    • D
      drm: Fixup racy refcounting in plane_force_disable · 220dd2bc
      Daniel Vetter 提交于
      Originally it was impossible to be dropping the last refcount in this
      function since there was always one around still from the idr. But in
      
      commit 83f45fc3
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Aug 6 09:10:18 2014 +0200
      
          drm: Don't grab an fb reference for the idr
      
      we've switched to weak references, broke that assumption but forgot to
      fix it up.
      
      Since we still force-disable planes it's only possible to hit this
      when racing multiple rmfb with fbdev restoring or similar evil things.
      As long as userspace is nice it's impossible to hit the BUG_ON.
      
      But the BUG_ON would most likely be hit from fbdev code, which usually
      invovles the console_lock besides all modeset locks. So very likely
      we'd never get the bug reports if this was hit in the wild, hence
      better be safe than sorry and backport.
      
      Spotted by Matt Roper while reviewing other patches.
      
      Cc: stable@vger.kernel.org
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      220dd2bc
    • D
      drm: Remove redundant code in the getencoder ioctl · 84428531
      Daniel Vetter 提交于
      When enabling atomic state object for this ioctl in
      
      commit abd69c55
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Nov 25 23:50:05 2014 +0100
      
          drm: Handle atomic state properly in kms getfoo ioctl
      
      I've forgotten to remove this hunk in one of the later revisions.
      drm_encoder_get_crtc already does this.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      84428531
    • C
      drm: Don't assign fbs for universal cursor support to files · 9a6f5130
      Chris Wilson 提交于
      The internal framebuffers we create to remap legacy cursor ioctls to
      plane operations for the universal plane support shouldn't be linke to
      the file like normal userspace framebuffers. This bug goes back to the
      original universal cursor plane support introduced in
      
      commit 161d0dc1
      Author: Matt Roper <matthew.d.roper@intel.com>
      Date:   Tue Jun 10 08:28:10 2014 -0700
      
          drm: Support legacy cursor ioctls via universal planes when possible (v4)
      
      The isn't too disastrous since fbs are small, we only create one when the
      cursor bo gets changed and ultimately they'll be reaped when the window
      server restarts.
      
      Conceptually we'd want to just pass NULL for file_priv when creating it,
      but the driver needs the file to lookup the underlying buffer object for
      cursor id. Instead let's move the file_priv linking out of
      add_framebuffer_internal() into the addfb ioctl implementation, which is
      the only place it is needed. And also rename the function for a more
      accurate since it only creates the fb, but doesn't add it anywhere.
      
      Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9a6f5130
  17. 24 2月, 2015 1 次提交
  18. 23 2月, 2015 1 次提交
  19. 14 2月, 2015 1 次提交
    • R
      drm: add support for tiled/compressed/etc modifier in addfb2 · e3eb3250
      Rob Clark 提交于
      In DRM/KMS we are lacking a good way to deal with tiled/compressed
      formats.  Especially in the case of dmabuf/prime buffer sharing, where
      we cannot always rely on under-the-hood flags passed to driver specific
      gem-create ioctl to pass around these extra flags.
      
      The proposal is to add a per-plane format modifier.  This allows to, if
      necessary, use different tiling patters for sub-sampled planes, etc.
      The format modifiers are added at the end of the ioctl struct, so for
      legacy userspace it will be zero padded.
      
      v1: original
      v1.5: increase modifier to 64b
      
      v2: Incorporate review comments from the big thread, plus a few more.
      
      - Add a getcap so that userspace doesn't have to jump through hoops.
      - Allow modifiers only when a flag is set. That way drivers know when
        they're dealing with old userspace and need to fish out e.g. tiling
        from other information.
      - After rolling out checks for ->modifier to all drivers I've decided
        that this is way too fragile and needs an explicit opt-in flag. So
        do that instead.
      - Add a define (just for documentation really) for the "NONE"
        modifier. Imo we don't need to add mask #defines since drivers
        really should only do exact matches against values defined with
        fourcc_mod_code.
      - Drop the Samsung tiling modifier on Rob's request since he's not yet
        sure whether that one is accurate.
      
      v3:
      - Also add a new ->modifier[] array to struct drm_framebuffer and fill
        it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin.
      - Remove TODO in comment and add code comment that modifiers should be
        properly documented, requested by Rob.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Daniel Stone <daniel@fooishbar.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Michel Dänzer <michel@daenzer.net>
      Signed-off-by: Rob Clark <robdclark@gmail.com> (v1.5)
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NDaniel Stone <daniels@collabora.com>
      Acked-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      e3eb3250
  20. 28 1月, 2015 3 次提交
  21. 27 1月, 2015 3 次提交
    • D
      drm/atomic: Add drm_crtc_state->active · eab3bbef
      Daniel Vetter 提交于
      This is the infrastructure for DPMS ported to the atomic world.
      Fundamental changes compare to legacy DPMS are:
      
      - No more per-connector dpms state, instead there's just one per each
        display pipeline. So if you clone either you have to unclone first
        if you only want to switch off one screen, or you just switch of
        everything (like all desktops do). This massively reduces complexity
        for cloning since now there's no more half-enabled cloned configs to
        consider.
      
      - Only on/off, dpms standby/suspend are as dead as real CRTs. Again
        reduces complexity a lot.
      
      Now especially for backwards compat the really important part for dpms
      support is that dpms on always succeeds (except for hw death and
      unplugged cables ofc). Which means everything that could fail (like
      configuration checking, resources assignments and buffer management)
      must be done irrespective from ->active. ->active is really only a
      toggle to change the hardware state. More precisely:
      
      - Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
        Changes to ->active MUST always suceed if nothing else changes.
      
      - Drivers using the atomic helpers MUST NOT look at ->active anywhere,
        period. The helpers will take care of calling the respective
        enable/modeset/disable hooks as necessary. As before the helpers
        will carefully keep track of the state and not call any hooks
        unecessarily, so still no double-disables or enables like with crtc
        helpers.
      
      - ->mode_set hooks are only called when the mode or output
        configuration changes, not for changes in ->active state.
      
      - Drivers which reconstruct the state objects in their ->reset hooks
        or through some other hw state readout infrastructure must ensure
        that ->active reflects actual hw state.
      
      This just implements the core bits and helper logic, a subsequent
      patch will implement the helper code to implement legacy dpms with
      this.
      
      v2: Rebase on top of the drm ioctl work:
      - Move crtc checks to the core check function.
      - Also check for ->active_changed when deciding whether a modeset
        might happen (for the ALLOW_MODESET mode).
      - Expose the ->active state with an atomic prop.
      
      v3: Review from Rob
      - Spelling fix in comment.
      - Extract needs_modeset helper to consolidate the ->mode_changed ||
        ->active_changed checks.
      
      v4: Fixup fumble between crtc->state and crtc_state.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Tested-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      eab3bbef
    • D
      drm: Add standardized boolean props · 960cd9d4
      Daniel Vetter 提交于
      Not a new type exposed to userspace, just a standard way to create
      them since between range, bitmask and enum there's 3 different ways to
      pull out a boolean prop.
      
      Also add the kerneldoc for the recently added new prop types, which
      Rob forgot all about.
      
      v2: Fixup kerneldoc, spotted by Rob.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      960cd9d4
    • B
      drm: fix drm_display_info_set_bus_formats kernel doc header · e37bfa1a
      Boris Brezillon 提交于
      formats and num_formats arguments were previously called fmts and nfmts.
      Fix the kernel doc comment so that it matches the new argument names.
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e37bfa1a
  22. 21 1月, 2015 1 次提交
  23. 13 1月, 2015 1 次提交
  24. 05 1月, 2015 1 次提交
    • R
      drm: Atomic modeset ioctl · d34f20d6
      Rob Clark 提交于
      The atomic modeset ioctl can be used to push any number of new values
      for object properties. The driver can then check the full device
      configuration as single unit, and try to apply the changes atomically.
      
      The ioctl simply takes a list of object IDs and property IDs and their
      values.
      
      Originally based on a patch from Ville Syrjälä, although it has mutated
      (mutilated?) enough since then that you probably shouldn't blame it on
      him ;-)
      
      The atomic support is hidden behind the DRM_CLIENT_CAP_ATOMIC cap (to
      protect legacy userspace) and drm.atomic module param (for now).
      
      v2: Check for file_priv->atomic to make sure we only allow userspace
      in-the-know to use atomic.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d34f20d6