1. 10 3月, 2015 1 次提交
  2. 24 2月, 2015 1 次提交
  3. 23 2月, 2015 1 次提交
  4. 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
  5. 28 1月, 2015 3 次提交
  6. 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
  7. 21 1月, 2015 1 次提交
  8. 13 1月, 2015 1 次提交
  9. 05 1月, 2015 5 次提交
  10. 19 12月, 2014 2 次提交
  11. 18 12月, 2014 4 次提交
  12. 10 12月, 2014 8 次提交
  13. 09 12月, 2014 4 次提交
  14. 06 12月, 2014 1 次提交
  15. 27 11月, 2014 2 次提交
    • D
      drm: Handle atomic state properly in kms getfoo ioctl · abd69c55
      Daniel Vetter 提交于
      So the problem with async commit (especially async modeset commit) is
      that the legacy pointers only get updated after the point of no
      return, in the async part of the modeset sequence. At least as
      implemented by the current helper functions. This is done in the
      set_routing_links function in drm_atomic_helper.c.
      
      Which also means that access isn't protected by locks but only
      coordinated by synchronizing with async workers. No problem thus far,
      until we lock at the getconnector/encoder ioctls.
      
      So fix this up by adding special cases for atomic drivers: For those
      we need to look at state objects. Unfortunately digging out the
      correct encoder->crtc link is a bit of work, so wrap this up in a
      helper function.
      
      Moving the assignments of connector->encoder and encoder->crtc earlier
      isn't a good idea because the point of the atomic helpers is that we
      stage the state updates. That way the disable functions can still
      inspect the links and rely upon them.
      
      v2: Extract full encoder->crtc lookup into helper (Rob).
      
      v3: Extract drm_connector_get_encoder too since - we need to always
      return state->best_encoder when there is a state otherwise we might
      return stale data if there's a pending async disable (and chase
      unlocked pointers, too). Same issue with encoder_get_crtc but there
      it's a bit more tricky to handle.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Lightly-Tested-by: NSean Paul <seanpaul@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      abd69c55
    • R
      drm: use mode_object_find helpers · 933f622f
      Rob Clark 提交于
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      933f622f
  16. 25 11月, 2014 1 次提交
  17. 20 11月, 2014 1 次提交
    • D
      drm: s/enum_blob_list/enum_list/ in drm_property · 3758b341
      Daniel Vetter 提交于
      I guess for hysterical raisins this was meant to be the way to read
      blob properties. But that's done with the two-stage approach which
      uses separate blob kms object and the special-purpose get_blob ioctl.
      
      Shipping userspace seems to have never relied on this, and the kernel
      also never put any blob thing onto that property. And nowadays it
      would blow up, e.g. in drm_property_destroy. Also it makes no sense to
      return values in an ioctl that only returns metadata about everything.
      
      So let's ditch all the internal code for the blob list, rename the
      list to be unambiguous and sprinkle comments all over the place to
      explain this peculiar piece of api.
      
      v2: Squash in fixup from Rob to remove now unused variables.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3758b341