1. 09 9月, 2018 1 次提交
  2. 08 9月, 2018 1 次提交
  3. 06 9月, 2018 5 次提交
  4. 04 9月, 2018 1 次提交
  5. 31 8月, 2018 1 次提交
  6. 25 8月, 2018 1 次提交
    • L
      drm: Add per-plane pixel blend mode property · a5ec8332
      Lowry Li 提交于
      Pixel blend modes represent the alpha blending equation
      selection, describing how the pixels from the current
      plane are composited with the background.
      
      Adds a pixel_blend_mode to drm_plane_state and a
      blend_mode_property to drm_plane, and related support
      functions.
      
      Defines three blend modes in drm_blend.h.
      
      Changes since v1:
       - Moves the blending equation into the DOC comment
       - Refines the comments of drm_plane_create_blend_mode_property to not
         enumerate the #defines, but instead the string values
       - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
      Changes since v2:
       - Refines the comments of drm_plane_create_blend_mode_property:
            1) Puts the descriptions (after the ":") on a new line
            2) Adds explaining why @supported_modes need PREMUL as default
      Changes since v3:
       - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
         can calculate the index itself just fine, so no point in having the
         caller pass it in.
       - Since the current DRM assumption is that alpha is premultiplied
         as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
       - Refines some comments.
      Changes since v4:
       - Adds comments in drm_blend.h.
       - Removes setting default value in drm_plane_create_blend_mode_property()
         as it is already in __drm_atomic_helper_plane_reset().
       - Fixes to use state->pixel_blend_mode instead of using
         plane->state->pixel_blend_mode in reset function.
       - Rebases on drm-misc-next.
      Reviewed-by: NLiviu Dudau <liviu.dudau@arm.com>
      Signed-off-by: NLowry Li <lowry.li@arm.com>
      Signed-off-by: NAyan Kumar Halder <ayan.halder@arm.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/245734/
      a5ec8332
  7. 23 8月, 2018 2 次提交
  8. 16 8月, 2018 1 次提交
  9. 15 8月, 2018 1 次提交
  10. 13 8月, 2018 2 次提交
  11. 08 8月, 2018 1 次提交
  12. 06 8月, 2018 1 次提交
  13. 02 8月, 2018 1 次提交
  14. 01 8月, 2018 1 次提交
  15. 30 7月, 2018 4 次提交
  16. 28 7月, 2018 1 次提交
  17. 26 7月, 2018 2 次提交
  18. 20 7月, 2018 1 次提交
  19. 18 7月, 2018 3 次提交
    • A
      drm/fourcc: Add is_yuv field to drm_format_info to denote if the format is yuv · ce2d5461
      Ayan Kumar Halder 提交于
      A lot of drivers duplicate the function to check if a format is yuv or not.
      If we add a field (to denote whether the format is yuv or not) in the
      drm_format_info table, all the drivers can use this field and it will
      prevent duplication of similar logic.
      Signed-off-by: NAyan Kumar halder <ayan.halder@arm.com>
      Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1531847626-22248-1-git-send-email-ayan.halder@arm.com
      ce2d5461
    • T
      ALSA: hda: Make audio component support more generic · a57942bf
      Takashi Iwai 提交于
      This is the final step for more generic support of DRM audio
      component.  The generic audio component code is now moved to its own
      file, and the symbols are renamed from snd_hac_i915_* to
      snd_hdac_acomp_*, respectively.  The generic code is enabled via the
      new kconfig, CONFIG_SND_HDA_COMPONENT, while CONFIG_SND_HDA_I915 is
      kept as the super-class.
      
      Along with the split, three new callbacks are added to audio_ops:
      pin2port is for providing the conversion between the pin number and
      the widget id, and master_bind/master_unbin are called at binding /
      unbinding the master component, respectively.  All these are optional,
      but used in i915 implementation and also other later implementations.
      
      A note about the new snd_hdac_acomp_init() function: there is a slight
      difference between this and the old snd_hdac_i915_init().  The latter
      (still) synchronizes with the master component binding, i.e. it
      assures that the relevant DRM component gets bound when it returns, or
      gives a negative error.  Meanwhile the new function doesn't
      synchronize but just leaves as is.  It's the responsibility by the
      caller's side to synchronize, or the caller may accept the
      asynchronous binding on the fly.
      
      v1->v2: Fix missing NULL check in master_bind/unbind
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a57942bf
    • T
      drm/i915: Split audio component to a generic type · ae891abe
      Takashi Iwai 提交于
      For allowing other drivers to use the DRM audio component, rename the
      i915_audio_component_* with drm_audio_component_*, and split the
      generic part into drm_audio_component.h.  The i915 specific stuff
      remains in struct i915_audio_component, which contains
      drm_audio_component as the base.
      
      The license of drm_audio_component.h is kept to MIT as same as the the
      original i915_component.h.
      
      This is a preliminary change for further development, and no
      functional changes by this patch itself, merely code-split and
      renames.
      
      v1->v2: Use SPDX for drm_audio_component.h, fix remaining i915
              argument in drm_audio_component.h
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ae891abe
  20. 16 7月, 2018 1 次提交
    • L
      drm/dp_helper: Add DP aux channel tracing · a18b2192
      Lyude Paul 提交于
      This is something we've needed for a very long time now, as it makes
      debugging issues with faulty MST hubs along with debugging issues
      regarding us interfacing with hubs correctly vastly easier to debug.
      Currently this can actually be done if you trace the i2c devices for DP
      using ftrace but that's significantly less useful for a couple of
      reasons:
      
      - Tracing the i2c devices through ftrace means all of the traces are
        going to contain a lot of "garbage" output that we're sending over the
        i2c line. Most of this garbage comes from retrying transactions, DRM's
        helper library adding extra transactions to work around bad hubs, etc.
      - Having a user set up ftrace so that they can provide debugging
        information is a lot more difficult then being able to say "just boot
        with drm.debug=0x100"
      - We can potentially expand upon this tracing in the future to print
        debugging information in regards to other DP transactions like MST
        sideband transactions
      
      This is inspired by a patch Rob Clark sent to do this a long time back.
      Neither of us could find the patch however, so we both assumed it would
      probably just be easier to rewrite it anyway.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180716154432.13433-1-lyude@redhat.com
      a18b2192
  21. 14 7月, 2018 8 次提交