1. 18 May, 2018 21 commits
  2. 17 May, 2018 4 commits
    • Stanislav Lisovskiy's avatar
      i915: content-type property for HDMI connector · 6553b123
      Stanislav Lisovskiy authored
      Added encoding of drm content_type property from drm_connector_state
      within AVI infoframe in order to properly handle external HDMI TV
      content-type setting.
      
      This requires also manipulationg ITC bit, as stated in
      HDMI spec.
      
      v2:
       * Moved helper function which attaches content type property
         to the drm core, as was suggested.
         Removed redundant connector state initialization.
      
      v3:
       * Removed caps in drm_content_type_enum_list.
         After some discussion it turned out that HDMI Spec 1.4
         was wrongly assuming that IT Content(itc) bit doesn't affect
         Content type states, however itc bit needs to be manupulated
         as well. In order to not expose additional property for itc,
         for sake of simplicity it was decided to bind those together
         in same "content type" property.
      
      v4:
       * Added it_content checking in intel_digital_connector_atomic_check.
         Fixed documentation for new content type enum.
      
      v5:
       * Moved patch revision's description to commit messages.
      
      v6:
       * Minor naming fix for the content type enumeration string.
      
      v7:
       * Fix parameter name for documentation and parameter alignment
         in order not to get warning. Added Content Type description to
         new HDMI connector properties section.
      
      v8:
       * Thrown away unneeded numbers from HDMI content-type property
         description. Switch to strings desription instead of plain
         definitions.
      
      v9:
       * Moved away hdmi specific content-type enum from
         drm_connector_state. Content type property should probably not
         be bound to any specific connector interface in
         drm_connector_state.
         Same probably should be done to hdmi_picture_aspect_ration enum
         which is also contained in drm_connector_state. Added special
         helper function to get derive hdmi specific relevant infoframe
         fields.
      
      v10:
       * Added usage description to HDMI properties kernel doc.
      
      v11:
       * Created centralized function for filling HDMI AVI infoframe, based
         on correspondent DRM property value.
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-3-stanislav.lisovskiy@intel.com
      [vsyrjala: clean up checkpatch multiple blank lines warnings]
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      6553b123
    • Stanislav Lisovskiy's avatar
      drm: content-type property for HDMI connector · 50525c33
      Stanislav Lisovskiy authored
      Added content_type property to drm_connector_state
      in order to properly handle external HDMI TV content-type setting.
      
      v2:
       * Moved helper function which attaches content type property
         to the drm core, as was suggested.
         Removed redundant connector state initialization.
      
      v3:
       * Removed caps in drm_content_type_enum_list.
         After some discussion it turned out that HDMI Spec 1.4
         was wrongly assuming that IT Content(itc) bit doesn't affect
         Content type states, however itc bit needs to be manupulated
         as well. In order to not expose additional property for itc,
         for sake of simplicity it was decided to bind those together
         in same "content type" property.
      
      v4:
       * Added it_content checking in intel_digital_connector_atomic_check.
         Fixed documentation for new content type enum.
      
      v5:
       * Moved patch revision's description to commit messages.
      
      v6:
       * Minor naming fix for the content type enumeration string.
      
      v7:
       * Fix parameter name for documentation and parameter alignment
         in order not to get warning. Added Content Type description to
         new HDMI connector properties section.
      
      v8:
       * Thrown away unneeded numbers from HDMI content-type property
         description. Switch to strings desription instead of plain
         definitions.
      
      v9:
       * Moved away hdmi specific content-type enum from
         drm_connector_state. Content type property should probably not
         be bound to any specific connector interface in
         drm_connector_state.
         Same probably should be done to hdmi_picture_aspect_ration enum
         which is also contained in drm_connector_state. Added special
         helper function to get derive hdmi specific relevant infoframe
         fields.
      
      v10:
       * Added usage description to HDMI properties kernel doc.
      
      v11:
       * Created centralized function for filling HDMI AVI infoframe, based
         on correspondent DRM property value.
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com
      [vsyrjala: clean up checkpatch multiple blank lines warnings]
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      50525c33
    • Philippe Cornu's avatar
    • Maxime Ripard's avatar
      drm/vc4: plane: Expand the lower bits by repeating the higher bits · 3257ec79
      Maxime Ripard authored
      The vc4 HVS uses an internal RGB888 representation of the frames, and will
      by default expand formats using a lower depth using zeros.
      
      This causes an issue when we try to use other compositing software such as
      pixman that fill the missing bits by repeating the higher significant bits.
      As such, we can't check the display output in a reliable way by doing a
      software composition and an hardware one and compare both.
      
      To prevent this, force the same behaviour so that we can do such things.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180517133759.25626-1-maxime.ripard@bootlin.com
      3257ec79
  3. 15 May, 2018 2 commits
  4. 14 May, 2018 3 commits
  5. 11 May, 2018 10 commits