08 Mar, 2018
3 commits
-
Fix the clock source selection for MIPI use-case.
Signed-off-by: Robert Chiras
-
According to CEA-861-E section 6.6.2, add channel/speaker
allocation configuration for 4 channel.
0x0: FL, FR
0x3: FL, FR, LFE, FC
0x1F:FL, FR, LFE, FC, RL, RR, FLC, FRCSigned-off-by: Shengjiu Wang
Reviewed-by: Sandor Yu
(cherry picked from commit 0b4e6f2d6377c34c18a382c13913a5c96c8a18e8) -
There is channel swapping issue for 4 channel and 8 channel audio.
After dump the register, found that SMPL2PKT_CNFG is not set
correctly, the reason is that F_NUM_OF_I2S_PORTS should be
F_NUM_OF_I2S_PORTS_S.Signed-off-by: Shengjiu Wang
Reviewed-by: Sandor Yu
(cherry picked from commit 0bb30f24474dfce7f4ad70343f5f39a645e4b407)
07 Mar, 2018
4 commits
-
The following commit:
af01350 - MLK-17634-18: drm: imx: dcss: optimize context loading and DDR
bus loadintroduced a regression. During my attempts to fix various green screen
issues, I modified the DTRC start routine by enabling the other register
bank, not the current one.Unfortunately, this was committed by mistake...
Signed-off-by: Laurentiu Palcu
(cherry picked from commit 2a6b73acb9c6f3a307d9a2d286991f16e4358514) -
HDR metadata infoframe was sent only when doing a mode set. However,
kmssink is using the same device as Weston and mode setting messes up
with Weston's plane state.This patch allows for the HDR metadata to be sent out to the sink when
the property is set. Hence, no need for a mode set.Also, the older functionality allowed only for 4K@60 to be used for HDR.
However, HDR is not about resolution. This patch will also allow to go
to HDR mode in other resolutions as well.Signed-off-by: Laurentiu Palcu
(cherry picked from commit f9d81db38258f09d2abe2b8d092c17b444179d08) -
Since DCSS was moved to use VIDEO2_PLL clock, HDMI phy clock is not used
anymore. Hence, this delay here is not necessary. It's been added inside
DCSS driver.Signed-off-by: Laurentiu Palcu
(cherry picked from commit aeff3bf78ced6e27a262c9022e658f57f5239c23) -
DCSS needs some time to stabilize after switching to a new pixel clock.
All interrupts will delayed till the clock stabilizes and we'll end up
getting warnings about VBLANK interrupt taking more than 50ms to arrive.This patch adds a 500ms delay after switching to a new clock. This will
allow DCSS to stabilize before enabling CRTC and DTG channels.Signed-off-by: Laurentiu Palcu
(cherry picked from commit 86764e4056be96583e1acebe0d31f5090dfb3822)
01 Mar, 2018
1 commit
-
The problem arised because of a combination of 2 commits:
Commit 1:
"2a70f32 - MLK-17232-2: drm: imx: dcss: ignore SB_PEND_DISP_ACTIVE
interrupt"disabled the SB_PEND_DISP_ACTIVE interrupt because of a problem in SOC.
However, it did not remove the flag from CTXLD_IRQ_ERROR macro.Commit 2:
"f0e3911 - MLK-17459-1: drm: imx: dcss: change ctxld irq handling"
moved the bottom half interrupt handling to top half. By doing that, the
top half did not exit immediately if IRQ_COMPLETION condition was met
and continued evaluating if any interrupts in CTXLD_IRQ_ERROR flags
were triggered.This patch removes SB_PEND_DISP_ACTIVE interrupt flag from
CTXLD_IRQ_ERROR macro.Signed-off-by: Laurentiu Palcu
28 Feb, 2018
32 commits
-
Signed-off-by: Laurentiu Palcu
-
This will lower the amount of ctxld entries sent, if configuration has
not changed much. Also, disable channel 0 if alpha is 0 and global alpha
is used. This will lower the DDR load, depending on graphics channel
resolution.Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
This patch adds basic HDR10 support. However, full support depends on
subsequent patches.Signed-off-by: Laurentiu Palcu
-
The tables header is no longer necessary as dcss.fw file will be used
from now on to store LUT and CSC tables.Signed-off-by: Laurentiu Palcu
-
If the HDR metadata proprety is set, then the metadata will be sent
to the sink at the next mode set.Signed-off-by: Laurentiu Palcu
-
This clock is needed by HDR10 so this patch makes DCSS use VIDEO2_PLL2
for the rest of the resolutions as well.Signed-off-by: Laurentiu Palcu
-
The SSCG PLL2 is identical to PLL1, hence make the rounding/setting
functions reflect that.Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)
V5: Addressed review comments from Danvet:
- %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type
- %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output
- %s/drm_can_support_this_ycbcr_output/
drm_display_supports_this_ycbcr_output
- pass drm_display_info instead of drm_connector for consistency
- For drm_get_highest_quality_ycbcr_supported doc, move the variable
description above, and then the function description.
V6: Add only YCBCR420 helpers (Ville)
V7: Addressed review comments from Ville
- Remove cea_vic_valid() check.
- Fix indentation.
- Make input parameters to helpers, const.Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Daniel Vetter
Signed-off-by: Shashank Sharma
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-9-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: Ville Syrjälä -
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: RebaseCc: 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ä -
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.This patch moves the call to drm_add_display_info function, before the
mode parsing block.V4: Introduced new patch in the series
V5: Move this patch before 4:2:0 parsing patch (ville)
Added r-b from Ville
V6: Rebase
V7: RebaseReviewed-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-4-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä -
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 VelikovV2: 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 bitmapSigned-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ä -
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"This patch renames the macro and usages from "VIDEO_CAPABILITY_BLOCK"
to "USE_EXTENDED_TAG"V2: Add extended tag code check for video capabilitiy block (ville)
V3: Ville:
- Use suggested names for macros
- Check the block length first, before checking the extended tag
V4: Fix commit message (David)
V5: Introduced this patch into HDMI-YCBCR-output series
V6: Rebase
V7: RebaseCc: Ville Syrjala
Signed-off-by: Shashank Sharma
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-5-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä -
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 patchCc: 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ä -
Signed-off-by: Laurentiu Palcu
-
The frame->type was overwritten, instead of setting the frame->metadata_type
field.Signed-off-by: Laurentiu Palcu
-
Signed-off-by: Laurentiu Palcu
-
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.Signed-off-by: Uma Shankar
-
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
-
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 -
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 -
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: RebaseSigned-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
Signed-off-by: Jani Nikula
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-3-git-send-email-shashank.sharma@intel.com -
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Addressed review comments from Ville
- Handle the I2c return values in a better way (dp_dual_mode)
- Make the macros for SCDC Major/Minor more readable, by adding
a 'GET' in the macro names
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: RebaseSigned-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
Signed-off-by: Jani Nikula
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-2-git-send-email-shashank.sharma@intel.com -
HDR source metadata set and get property implemented in this
patch. The blob data is received from userspace and saved in
connector state, the same is returned as blob in get property
call to userspace.Signed-off-by: Uma Shankar
-
Change drm_atomic_replace_property_blob_from_id()'s first parameter
from drm_crtc to drm_device, so that the function can be used for other
drm_mode_objects too.Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/851b8504c7f294a10645ba6f6d391ac9764068b7.1492768073.git.jsarha@ti.com -
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
