21 Mar, 2018

10 commits

• ac7b9993a   drm: add connector info/property for non-desktop displays [v2] ... Browse Code »

  This adds the infrastructure needed to quirk displays
  using edid and to mark them a non-desktop.

  A non-desktop display is one which shouldn't normally be included
  as a part of a desktop environment.

  This is meant to cover head mounted devices like HTC Vive.

  v2: Change description from non-standard to non-desktop, add docs

  Reviewed-by: Keith Packard
  Signed-off-by: Dave Airlie
  Signed-off-by: Marius Vlad

  (Ported 66660d4cf21b7dfcb25 from git://people.freedesktop.org/~airlied/linux)

  Dave Airlie

  2018-03-21 03:55:56 +0800  
• 09cf38af9   drm/edid: parse ycbcr 420 deep color information ... Browse Code »

  CEA-861-F spec adds ycbcr420 deep color support information
  in hf-vsdb block. This patch extends the existing hf-vsdb parsing
  function by adding parsing of ycbcr420 deep color support from the
  EDID and adding it into display information stored.

  V2: Rebase
  V3: Rebase
  V4: Moved definition of y420_dc_modes into this patch, where its used
  (Ville)
  V5: Optimize function, if(conditions) not reqd (Ville)
  V6: Rebase
  V7: Rebase

  Cc: Ville Syrjälä
  Cc: Jose Abreu
  Signed-off-by: Shashank Sharma
  Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-8-git-send-email-shashank.sharma@intel.com
  [vsyrjala: Fix sparse indentation warn]
  Signed-off-by: Ville Syrjälä

  Shashank Sharma

  2018-03-21 03:55:44 +0800  
• ee511cd0f   drm/edid: parse YCBCR420 videomodes from EDID ... Browse Code »

  HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
  CEA-861-F adds two new blocks in EDID's CEA extension blocks,
  to provide information about sink's YCBCR420 output capabilities.

  These blocks are:

  - YCBCR420vdb(YCBCR 420 video data block):
  This block contains VICs of video modes, which can be sopported only
  in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
  SVD block, valid for YCBCR420 modes only.

  - YCBCR420cmdb(YCBCR 420 capability map data block):
  This block gives information about video modes which can support
  YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
  block contains a bitmap index of normal svd videomodes, which can
  support YCBCR420 output too.
  So if bit 0 from first vcb byte is set, first video mode in the svd
  list can support YCBCR420 output too. Bit 1 means second video mode
  from svd list can support YCBCR420 output too, and so on.

  This patch adds two bitmaps in display's hdmi_info structure, one each
  for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
  adds:
  - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
  an entry in the vdb_bitmap per vic.
  - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

  Cc: Ville Syrjala
  Cc: Jose Abreu
  Cc: Emil Velikov

  V2: Addressed
  Review comments from Emil:
  - Use 1ULL<< 64 modes in capability map block.
  - Use y420cmdb in function names and macros while dealing with vcb
  to be aligned with spec.
  - Move the display information parsing block ahead of mode parsing
  blocks.

  V3: Addressed design/review comments from Ville
  - Do not add flags in video modes, else we have to expose them to user
  - There should not be a UABI change, and kernel should detect the
  choice of the output based on type of mode, and the bitmaps.
  - Use standard bitops from kernel bitmap header, instead of calculating
  bit positions manually.

  V4: Addressed review comments from Ville:
  - s/ycbcr_420_vdb/y420vdb
  - s/ycbcr_420_vcb/y420cmdb
  - Be less verbose on description of do_y420vdb_modes
  - Move newmode variable in the loop scope.
  - Use svd_to_vic() to get a VIC, instead of 0x7f
  - Remove bitmap description for CMDB modes & VDB modes
  - Dont add connector->ycbcr_420_allowed check for cmdb modes
  - Remove 'len' variable, in is_y420cmdb function, which is used
  only once
  - Add length check in is_y420vdb function
  - Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
  - Do not add print about YCBCR 420 modes
  - Fix indentation in few places
  - Move ycbcr420_dc_modes in next patch, where its used
  - Add a separate patch for movement of drm_add_display_info()

  V5: Addressed review comments from Ville:
  - Add the patch which cleans up the current EXTENDED_TAG usage
  - Make y420_cmdb_map u64
  - Do not block ycbcr420 modes while parsing the EDID, rather
  add a separate helper function to prune ycbcr420-only modes from
  connector's probed modes.

  V6: Rebase
  V7: Move this patch after the 420_only validation patch (Ville)
  V8: Addressed review comments from Ville
  - use cea_vic_valid check before adding cmdb/vdb modes
  - add check for i < 64 while adding cmdb modes
  - use 1ULL while checking bitmap

  Signed-off-by: Shashank Sharma
  Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
  [vsyrjala: Fix checkpatch complaints and indentation]
  Signed-off-by: Ville Syrjälä

  Shashank Sharma

  2018-03-21 03:55:43 +0800  
• 762fd7fc6   drm: add helper to validate YCBCR420 modes ... Browse Code »

  YCBCR420 modes are supported only on HDMI 2.0 capable sources.
  This patch adds:
  - A drm helper to validate YCBCR420-only mode on a particular
  connector. This function will help pruning the YCBCR420-only
  modes from the connector's modelist.
  - A bool variable (ycbcr_420_allowed) in the drm connector structure.
  While handling the EDID from HDMI 2.0 sinks, its important to know
  if the source is capable of handling YCBCR420 output, so that no
  YCBCR 420 modes will be listed for sources which can't handle it.
  A driver should set this variable if it wants to see YCBCR420 modes
  in the modedb.

  V5: Introduced the patch in series.
  V6: Squashed two patches (validate YCBCR420 and add YCBCR420
  identifier)
  V7: Addressed review comments from Vile:
  - Move this patch before we add 420 modes from EDID.
  - No need for drm_valid_cea_vic() check, function back to non-static.
  - Update MODE_STATUS with NO_420 condition.
  - Introduce y420_vdb_modes variable in this patch

  Cc: Ville Syrjala
  Signed-off-by: Shashank Sharma
  Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com
  [vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)]
  Signed-off-by: Ville Syrjälä

  Shashank Sharma

  2018-03-21 03:55:41 +0800  
• 77942b6e3   MLK-17634-4: drm: move hdr_panel_metadata to drm_hdmi_info ... Browse Code »

  Signed-off-by: Laurentiu Palcu

  Laurentiu Palcu

  2018-03-21 03:55:41 +0800  
• b4c01d018   drm: Parse Colorimetry data block from EDID ... Browse Code »

  EA 861.3 spec adds colorimetry data block for HDMI.
  Parsing the block to get the colorimetry data from
  panel.

  Signed-off-by: Uma Shankar

  Uma Shankar

  2018-03-21 03:55:38 +0800  
• cb9e0c3e6   drm/edid: detect SCDC support in HF-VSDB ... Browse Code »

  This patch does following:
  - Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
  - Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
  - Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
  - If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

  V2: Addressed review comments
  Thierry:
  - Fix typos in commit message and make abbreviation consistent
  across the commit message.
  - Change structure object name from hdmi_info -> hdmi
  - Fix typos and abbreviations in description of structure drm_hdmi_info
  end the description with a full stop.
  - Create a structure drm_scdc, and keep all information related to SCDC
  register set (supported, read request supported) etc in it.

  Ville:
  - Change rr -> read_request
  - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
  of HF-VSDB parsing can be kept in same function, in incremental
  patches.

  V3: Rebase.
  V4: Rebase.
  V5: Rebase.
  V6: Addressed review comments from Ville
  - Add clock rate calculations for 1/10 and 1/40 ratios
  - Remove leftovers from old patchset
  V7: Added R-B from Jose.
  V8: Rebase.
  V9: Rebase.
  V10: Rebase.

  Signed-off-by: Shashank Sharma
  Reviewed-by: Thierry Reding
  Reviewed-by: Jose Abreu
  Signed-off-by: Jani Nikula
  Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-5-git-send-email-shashank.sharma@intel.com

  Shashank Sharma

  2018-03-21 03:55:38 +0800  
• e20f01b00   drm/edid: detect SCDC support in HF-VSDB ... Browse Code »

  This patch does following:
  - Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
  - Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
  - Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
  - If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

  V2: Addressed review comments
  Thierry:
  - Fix typos in commit message and make abbreviation consistent
  across the commit message.
  - Change structure object name from hdmi_info -> hdmi
  - Fix typos and abbreviations in description of structure drm_hdmi_info
  end the description with a full stop.
  - Create a structure drm_scdc, and keep all information related to SCDC
  register set (supported, read request supported) etc in it.

  Ville:
  - Change rr -> read_request
  - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
  of HF-VSDB parsing can be kept in same function, in incremental
  patches.

  V3: Rebase.
  V4: Rebase.
  V5: Rebase.
  V6: Rebase.
  V7: Added R-B from Jose.
  V8: Rebase.
  V9: Rebase.
  V10: Rebase.

  Signed-off-by: Shashank Sharma
  Reviewed-by: Thierry Reding
  Reviewed-by: Jose Abreu
  Signed-off-by: Jani Nikula
  Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-4-git-send-email-shashank.sharma@intel.com

  Shashank Sharma

  2018-03-21 03:55:37 +0800  
• 775efd0be   drm: Add a new connector atomic property for link status ... Browse Code »

  At the time userspace does setcrtc, we've already promised the mode
  would work. The promise is based on the theoretical capabilities of
  the link, but it's possible we can't reach this in practice. The DP
  spec describes how the link should be reduced, but we can't reduce
  the link below the requirements of the mode. Black screen follows.

  One idea would be to have setcrtc return a failure. However, it
  already should not fail as the atomic checks have passed. It would
  also conflict with the idea of making setcrtc asynchronous in the
  future, returning before the actual mode setting and link training.

  Another idea is to train the link "upfront" at hotplug time, before
  pruning the mode list, so that we can do the pruning based on
  practical not theoretical capabilities. However, the changes for link
  training are pretty drastic, all for the sake of error handling and
  DP compliance, when the most common happy day scenario is the current
  approach of link training at mode setting time, using the optimal
  parameters for the mode. It is also not certain all hardware could do
  this without the pipe on; not even all our hardware can do this. Some
  of this can be solved, but not trivially.

  Both of the above ideas also fail to address link degradation *during*
  operation.

  The solution is to add a new "link-status" connector property in order
  to address link training failure in a way that:
  a) changes the current happy day scenario as little as possible, to
  avoid regressions, b) can be implemented the same way by all drm
  drivers, c) is still opt-in for the drivers and userspace, and opting
  out doesn't regress the user experience, d) doesn't prevent drivers
  from implementing better or alternate approaches, possibly without
  userspace involvement. And, of course, handles all the issues presented.
  In the usual happy day scenario, this is always "good". If something
  fails during or after a mode set, the kernel driver can set the link
  status to "bad" and issue a hotplug uevent for userspace to have it
  re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
  again. If the theoretical capabilities of the link can't be reached,
  the mode list is trimmed based on that.

  v7 by Jani:
  * Rebase, simplify set property while at it, checkpatch fix
  v6:
  * Fix a typo in kernel doc (Sean Paul)
  v5:
  * Clarify doc for silent rejection of atomic properties by driver (Daniel Vetter)
  v4:
  * Add comments in kernel-doc format (Daniel Vetter)
  * Update the kernel-doc for link-status (Sean Paul)
  v3:
  * Fixed a build error (Jani Saarinen)
  v2:
  * Removed connector->link_status (Daniel Vetter)
  * Set connector->state->link_status in drm_mode_connector_set_link_status_property
  (Daniel Vetter)
  * Set the connector_changed flag to true if connector->state->link_status changed.
  * Reset link_status to GOOD in update_output_state (Daniel Vetter)
  * Never allow userspace to set link status from Good To Bad (Daniel Vetter)

  Reviewed-by: Sean Paul
  Reviewed-by: Daniel Vetter
  Reviewed-by: Jani Nikula
  Acked-by: Tony Cheng
  Acked-by: Harry Wentland
  Cc: Jani Nikula
  Cc: Daniel Vetter
  Cc: Ville Syrjala
  Cc: Chris Wilson
  Cc: Sean Paul
  Signed-off-by: Manasi Navare
  Signed-off-by: Jani Nikula
  Acked-by: Eric Anholt (for the -modesetting patch)
  Signed-off-by: Daniel Vetter
  Link: http://patchwork.freedesktop.org/patch/msgid/0182487051aa9f1594820e35a4853de2f8747b4e.1481883920.git.jani.nikula@intel.com

  Manasi Navare

  2018-03-21 03:55:34 +0800  
• e3ccb592c   drm: Add HDR source metadata property ... Browse Code »

  This patch adds a blob property to get HDR metadata
  information from userspace. This will be send as part
  of AVI Infoframe to panel.

  Signed-off-by: Uma Shankar

  Uma Shankar

  2018-03-21 03:55:32 +0800