summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_psr.c
AgeCommit message (Collapse)AuthorFilesLines
2019-06-17drm/i915: move modesetting core code under display/Jani Nikula1-1303/+0
Now that we have a new subdirectory for display code, continue by moving modesetting core code. display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this is, again, a surprisingly clean operation. v2: - don't move intel_sideband.[ch] (Ville) - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-3-jani.nikula@intel.com
2019-06-17drm/i915: move modesetting output/encoder code under display/Jani Nikula1-1/+2
Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-2-jani.nikula@intel.com
2019-05-23drm: Rename struct edp_vsc_psr to struct dp_sdpGwan-gyeong Mun1-1/+1
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data Packet). In order to generalize SDP packet structure name, it renames struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have different usages, each SDP type has different reserved data blocks and Video_Stream_Configuration Extension VESA SDP might use all of Data Blocks as Extended INFORFRAME Data Byte. so it makes Data Block variables as array type. And it adds comments of details of DB of VSC SDP Payload for Pixel Encoding/Colorimetry Format. This comments follows DP 1.4a spec, section 2.2.5.7.5, chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format". v7: Addressed review comments from Ville. v9: Rename a member value name DB to db on struct dp_sdp [Laurent] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190521121721.32010-3-gwan-gyeong.mun@intel.com
2019-05-23drm/i915/dp: Add a config function for YCBCR420 outputsGwan-gyeong Mun1-10/+0
This patch checks a support of YCBCR420 outputs on an encoder level. If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420 output, else it continues with RGB output mode. It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using a pipe scaler as RGB to YCbCr 4:4:4. v2: Addressed review comments from Ville. Style fixed with few naming. %s/config/crtc_state/ %s/intel_crtc/crtc/ If lscon is active, it makes not to call intel_dp_ycbcr420_config() to avoid to clobber of lspcon_ycbcr420_config() routine. And it move the 420_only check into the intel_dp_ycbcr420_config(). v3: Fix uninitialized return value and it is reported by Dan Carpenter. v4: Addressed review comments from Ville. In order to avoid the extra indentation, it inverts if-clause on intel_dp_ycbcr420_config(). Remove the error print where no errors print are allowed. v6: Rebase v7: Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr. intel_dp_get_colorimetry_status() checks VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the DPRX_FEATURE_ENUMERATION_LIST register. And intel_dp_ycbcr420_config() uses intel_dp_get_colorimetry_status(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190521121721.32010-2-gwan-gyeong.mun@intel.com
2019-04-08drm/i915/psr: Do not enable PSR in interlaced mode for all GENsJosé Roberto de Souza1-3/+2
This interlaced mode restriction applies to all gens, not only to Haswell. Also while at it updating the debug message to. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-4-jose.souza@intel.com
2019-04-08drm/i915/psr: Initialize PSR mutex even when sink is not reliableJosé Roberto de Souza1-1/+0
Even when driver is reloaded and hits this scenario the PSR mutex should be initialized, otherwise reading PSR debugfs status will execute mutex_lock() over a mutex that was not initialized. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-3-jose.souza@intel.com
2019-04-08drm/i915/psr: Update PSR2 SU corruption workaround commentJosé Roberto de Souza1-4/+2
Turn out it is not a DMC bug it is actually a HW one, so this workaround will be needed for current gens, lets update the comment and remove the FIXME. BSpec: 7723 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-1-jose.souza@intel.com
2019-04-08drm/i915: extract intel_sprite.h from intel_drv.hJani Nikula1-0/+1
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/679c857a1933ee3d0706f978ab05ca880cd30a00.1554461791.git.jani.nikula@intel.com
2019-04-08drm/i915: extract intel_dp.h from intel_drv.hJani Nikula1-0/+1
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f86f9beed730eaad0bdcc18b18817b3d221e16e2.1554461791.git.jani.nikula@intel.com
2019-04-08drm/i915: extract intel_psr.h from intel_drv.hJani Nikula1-5/+6
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: Fix checkpatch whitespace complaint Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7e776690bf139ccdd0306b30df08dc68e74603de.1554461791.git.jani.nikula@intel.com
2019-03-26drm/i915: switch intel_wait_for_register to uncoreDaniele Ceraolo Spurio1-4/+4
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-9-daniele.ceraolospurio@intel.com
2019-03-19drm/i915: Fix PSR2 selective update corruption after PSR1 setupJosé Roberto de Souza1-0/+8
There is probably a issue in DMC firmwares(icl_dmc_ver1_07.bin and kbl_dmc_ver1_04.bin at least) that causes PSR2 SU to fail after exiting DC6 if EDP_PSR_TP1_TP3_SEL is kept in PSR_CTL, so for now lets workaround the issue by cleaning PSR_CTL before enable PSR2. v2: - Updated commit description and comment to state that it may be a DMC firmware issue (Rodrigo) - No need to RMW, let's write 0 to PSR_CTL(Dhinakaran) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314230113.6571-1-jose.souza@intel.com
2019-03-19drm/i915/psr: remove drmP.h include that crept inJani Nikula1-1/+0
We've been free of deprecated drmP.h includes for a while, but one crept in. Fend it off. Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190318160409.27648-1-jani.nikula@intel.com
2019-03-14drm/i915/icl+: Always use TPS2 or TPS3 when exiting PSR1José Roberto de Souza1-0/+3
When any other value than EDP_PSR_TP4_TIME_0US is set, TPS1 and TPS4 will be used to do the link training when exiting PSR1. Happily the eDP panels tested so far was able to sync with source even without HBR3/TPS4 support but let use the right training pattern. TPS4 support was added to PSR1 registers because HBR3/PSR specification was not closed when ICL was freezed so if HBR3 was supported by PSR, ICL would already be ready but it was not added to specification so lets always disable TPS4. v3: Missed ";" SPANK SPANK SPANK!!! BSpec: 17524 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190312195743.8829-3-jose.souza@intel.com
2019-03-14drm/i915/psr: Move logic to get TPS registers values to another functionJosé Roberto de Souza1-24/+33
This will make hsw_activate_psr1() more easy to read and will make future modification to TPS registers more easy to review and read. v4: Rename new function to intel_psr1_get_tp_time() (Dhinakaran and Rodrigo) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190312195743.8829-2-jose.souza@intel.com
2019-03-14drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup timeJosé Roberto de Souza1-4/+4
A new field with the training pattern(TP) wakeup time for PSR2 was added to VBT, so lets use it when available otherwise it will fallback to PSR1 wakeup time. v2: replacing enum to numerical usec time (Jani) BSpec: 20131 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190312195743.8829-1-jose.souza@intel.com
2019-03-08drm/i915: Enable PSR2 by defaultJosé Roberto de Souza1-3/+0
The support for PSR2 was polished, IGT tests for PSR2 was added and it was tested performing regular user workloads like browsing, editing documents and compiling Linux, so it is time to enable it by default and enjoy even more power-savings. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-9-jose.souza@intel.com
2019-03-08drm/i915: Force PSR1 exit when getting pipe CRCJosé Roberto de Souza1-13/+23
If PSR1 is active when pipe CRC is enabled the CRC calculations will be inhibit by the transition to low power states that PSR1 brings. So lets force a PSR1 exit and as soon as pipe CRC is enabled it will block PSR1 activation and avoid CRC timeouts when running IGT tests. There is a little window between the call to force exit PSR and the write to pipe CRC registers that needs to happen within the minimum of 6 idles frames otherwise PSR1 will be active again causing the CRC timeouts but anyways this will at least reduce the occurrence of CRC timeouts. This can possibily fix issues present right now but I did not found any open, I mostly got this issue from previous CI runs of this series, bellow some exambles: * igt@kms_color@pipe-b-ctm-0-75: - shard-apl: PASS -> FAIL +9 * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy: - shard-apl: PASS -> DMESG-FAIL +17 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt: - shard-kbl: PASS -> DMESG-FAIL +12 * igt@kms_pipe_crc_basic@read-crc-pipe-c: - shard-kbl: PASS -> FAIL +7 v6: s/PSR/PSR1 (Dhinakaran) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-8-jose.souza@intel.com
2019-03-08drm/i915: Drop redundant checks to update PSR stateJosé Roberto de Souza1-8/+4
All of this checks are redudant and can be removed as the if bellow already takes care when there is no changes in the state. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-7-jose.souza@intel.com
2019-03-08drm/i915: Disable PSR2 while getting pipe CRCJosé Roberto de Souza1-0/+5
When PSR2 is active aka after the number of frames programmed in PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC interrupts causing IGT tests to fail due timeout. This same behavior don't happen with PSR1, as soon as pipe CRC is enabled it blocks PSR1 activation so CRC calculation continues to happens normaly. This patch also set mode_changed as true when PSR is available to force atomic check functions to compute new PSR state, otherwise PSR2 would not be disabled. v4: Only setting mode_changed if has_psr is set(Dhinakaran) v3: Reusing intel_crtc_crc_prepare() and crc_enabled, only setting mode_changed if it can do PSR. v2: Changed commit description to describe that PSR2 inhibit CRC calculations. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-6-jose.souza@intel.com
2019-03-08drm/i915/psr: Drop test for EDP in CRTC when forcing commitJosé Roberto de Souza1-3/+1
If has_psr is set it means that CRTC has a EDP panel attached so the EDP check is redundant and can be dropped. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-4-jose.souza@intel.com
2019-03-08drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastsetJosé Roberto de Souza1-1/+2
Forcing a specific CRTC to the eDP connector was causing the intel_psr_fastset_force() to mark mode_chaged in the wrong and disabled CRTC causing no update in the PSR state. Looks like our internal state track do not clear output_types and has_psr in the disabled CRTCs, not sure if this is the expected behavior or not but in the mean time this fix the issue. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-2-jose.souza@intel.com
2019-03-08drm/i915/psr: Remove PSR2 FIXMEJosé Roberto de Souza1-5/+0
Now we are checking sink capabilities when probing PSR DPCD register and then dynamically checking in if new state is compatible with PSR in, so this FIXME can be dropped. Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-1-jose.souza@intel.com
2019-02-08drm/i915/psr: Execute the default PSR code path when setting i915_edp_psr_debugJosé Roberto de Souza1-75/+107
Changing the i915_edp_psr_debug was enabling, disabling or switching PSR version by directly calling intel_psr_disable_locked() and intel_psr_enable_locked(), what is not the default PSR path that will be executed by real users. So lets force a fastset in the PSR CRTC to trigger a pipe update and stress the default code path. Recently a bug was found when switching from PSR2 to PSR1 while enable_psr kernel parameter was set to the default parameter, this changes fix it and also fixes the bug linked bellow were DRRS was left enabled together with PSR when enabling PSR from debugfs. v2: Handling missing case: disabled to PSR1 v3: Not duplicating the whole atomic state(Maarten) v4: Adding back the missing call to intel_psr_irq_control(Dhinakaran) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341 Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190206211845.5322-1-jose.souza@intel.com
2019-01-23drm/i915/psr: Allow PSR2 to be enabled when debugfs asksJosé Roberto de Souza1-4/+4
For now PSR2 is still disabled by default for all platforms but is our intention to let debugfs to enable it for debug and tests proporses, so intel_psr2_enabled() that is also used by debugfs to decide if PSR2 is going to be enabled needs to take in consideration the debug field. v2: Using the switch/case that intel_psr2_enabled() already had to handle this(DK) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190117205548.28378-1-jose.souza@intel.com
2019-01-17drm/i915: small isolated c99 types to kernel types switchJani Nikula1-3/+3
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Minor checkpatch fixes sprinkled on top of the changed lines. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/14ed72e7f04c9340a057855c5950b54811f8a477.1547629303.git.jani.nikula@intel.com
2019-01-09drm/i915: drop all drmP.h includesJani Nikula1-1/+0
Needs just a few additional includes here and there. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com
2018-12-13drm/i915: replace IS_GEN<N> with IS_GEN(..., N)Lucas De Marchi1-2/+2
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-04drm/i915/psr: Check if source supports sink specific SU granularityJosé Roberto de Souza1-4/+33
According to eDP spec, sink can required specific selective update granularity that source must comply. Here caching the value if required and checking if source supports it. v3: - Returning the default granularity in case DPCD read fails(Dhinakaran) - Changed DPCD error message level(Dhinakaran) v4: - Setting granularity to defaul when granularity read is equal to 0(Dhinakaran) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-9-jose.souza@intel.com
2018-12-04drm/i915/psr: Check if resolution is supported by default SU granularityJosé Roberto de Souza1-0/+11
Selective updates have a default granularity requirements as stated by eDP spec(PSR2 SELECTIVE UPDATE X GRANULARITY CAPABILITY register definition), so check if HW can match those requirements before enabling PSR2. v3: - Changes in the comments and commit message(Dhinakaran) - Printing the hdisplay that do not match with default granularity Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-8-jose.souza@intel.com
2018-12-04drm/i915: Remove old PSR2 FIXME about frontbuffer trackingJosé Roberto de Souza1-3/+0
Our frontbuffer tracking improved over the years + the WA #0884 helped us keep PSR2 enabled while triggering screen updates when necessary so this FIXME is not valid anymore. Acked-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-6-jose.souza@intel.com
2018-12-04drm/i915/icl: Do not change reserved registers related to PSR2José Roberto de Souza1-7/+4
For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already unset in gen10 + GLK we can just drop it and fix for both gens. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-5-jose.souza@intel.com
2018-12-04drm/i915/psr: Enable sink to trigger a interruption on PSR2 CRC mismatchJosé Roberto de Souza1-1/+1
eDP spec states 2 different bits to enable sink to trigger a interruption when there is a CRC mismatch. DP_PSR_CRC_VERIFICATION is for PSR only and DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-4-jose.souza@intel.com
2018-12-04drm/i915/psr: Set PSR CRC verification bit in sink inside PSR1 blockJosé Roberto de Souza1-2/+3
As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {' and this bit is only set for PSR1 move it to that block to make it more easy to read. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-3-jose.souza@intel.com
2018-12-04drm/i915/psr: Don't tell sink that main link will be active while is active PSR2José Roberto de Souza1-2/+3
For PSR2 there is no register to tell HW to keep main link enabled while PSR2 is active, so don't configure sink DPCD with a misleading value. v2: Moving the set of DP_PSR_CRC_VERIFICATION to the else block of 'if (dev_priv->psr.psr2_enabled)' to another patch. (Rodrigo) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-2-jose.souza@intel.com
2018-12-04drm/i915: Disable PSR in Apple panelsJosé Roberto de Souza1-0/+6
i915 yet don't support PSR in Apple panels, so lets keep it disabled while we work on that. v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to DP_DPCD_QUIRK_NO_PSR (Ville) v3: Adding documentation to DP_DPCD_QUIRK_NO_PSR(Dhinakaran and Jani) Fixed typo in comment of the new quirk entry(Jani) Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-1-jose.souza@intel.com
2018-11-30drm/i915/psr: Get pipe id following atomic guidelinesJosé Roberto de Souza1-15/+4
As stated in struct drm_encoder, crtc field should only be used by non-atomic drivers. So here caching the pipe id in intel_psr_enable() what is way more simple and efficient than at every call to intel_psr_flush()/invalidate() get the drm.mode_config.connection_mutex lock to safely be able to get the pipe id by reading drm_connector_state.crtc. This should fix the null pointer dereference crash below as the previous way to get the pipe id was prone to race conditions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105959 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128072838.22773-1-jose.souza@intel.com
2018-11-29drm/i915/dp: Do not enable PSR2 if DSC is enabledManasi Navare1-0/+14
If a eDP panel supports both PSR2 and VDSC, our HW cannot support both at a time. Give priority to PSR2 if a requested resolution can be supported without compression else enable VDSC and keep PSR2 disabled. v4: Fix the unrealted stuff removed during rebase (Ville) v3: * Rebase v2: * Add warning for DSC and PSR2 enabled together (DK) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-3-manasi.d.navare@intel.com
2018-11-23drm/i915/hsw: Drop the stereo 3D enabled check in psr_compute_config()José Roberto de Souza1-7/+0
We should not access hardware while computing config also we don't support stereo 3D so this test was never true. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-6-jose.souza@intel.com
2018-11-23drm/i915: Keep PSR disabled after a driver reload after a PSR errorJosé Roberto de Souza1-0/+18
If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR will still keep the error set even after the reset done in the irq_preinstall and irq_uninstall hooks. And enabling in this situation cause the screen to freeze in the first time that PSR HW tries to activate so lets keep PSR disabled to avoid any rendering problems. v5: rebased: using edp_psr_shift() v4: Moved handling from intel_psr_compute_config() to intel_psr_init() to avoid hardware access during compute(Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> squash Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-5-jose.souza@intel.com
2018-11-23drm/i915: Disable PSR when a PSR aux error happenJosé Roberto de Souza1-4/+37
While PSR is active hardware will do aux transactions by it self to wakeup sink to receive a new frame when necessary. If that transaction is not acked by sink, hardware will trigger this interruption. So let's disable PSR as it is a hint that there is problem with this sink. The removed FIXME was asking to manually train the link but we don't need to do that as by spec sink should do a short pulse when it is out of sync with source, we just need to make sure it is awaken and the SDP header with PSR inactive set it will trigger the short pulse with a error set in the link status. v3: added workarround to fix scheduled work starvation cause by to frequent PSR error interruption v4: only setting irq_aux_error as we don't care in clear it and not using dev_priv->irq_lock as consequence. v5: rebased: using edp_psr_shift() Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-4-jose.souza@intel.com
2018-11-23drm/i915: Do not enable PSR in the next modeset after a errorJosé Roberto de Souza1-1/+9
When we detect a error and disable PSR, it is kept disabled until the next modeset but as the sink already show signs that it do not properly work with PSR lets disabled it for good to avoid any additional flickering. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-3-jose.souza@intel.com
2018-11-23drm/i915: Check PSR errors instead of retrain while PSR is enabledJosé Roberto de Souza1-0/+15
When a PSR error happens sink sets the PSR error register and also set the link status to a error status. So in the short pulse handling it was returning earlier and doing a full detection and attempting to retrain but it fails as PSR HW is in change of the main-link. Just call intel_psr_short_pulse() before intel_dp_needs_link_retrain() is not the right fix as intel_dp_needs_link_retrain() would return true and trigger a full detection while PSR HW is still in change of main-link. Check for PSR active is also not safe as it could be inactive due a frontbuffer invalidate and still doing the PSR exit sequence. v3: added comment in intel_dp_needs_link_retrain() Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-2-jose.souza@intel.com
2018-11-21drm/i915: Make CHICKEN_TRANS reg not depend on enum valueImre Deak1-2/+23
Depending on the transcoder enum values to translate from transcoder to the corresponding CHICKEN_TRANS register can easily break if we add a new transcoder. Add an explicit mapping instead, by using helpers to look up the register instance either by transcoder or port (since unconveniently the registers have both port and transcoder specific bits). While at it also check for the correctness of GEN, port, transcoder. I wasn't sure if psr2_enabled can only be set for GEN9+, but that seems to be the case indeed (see setting of sink_psr2_support in intel_psr_init_dpcd()). v2 (Ville): - Make gen9_chicken_trans_reg() internal to intel_psr.c. - s/trans/cpu_transcoder/ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181119180021.370-1-imre.deak@intel.com
2018-11-21drm/i915: Make EDP PSR flags not depend on enum valuesImre Deak1-18/+37
Depending on the transcoder enum values to translate from transcoder to EDP PSR flags can easily break if we add a new transcoder. So remove the dependency by using an explicit mapping. While at it also add a WARN for unexpected trancoders. v2: - Simplify things by defining flag shift values instead of indices. - s/trans/cpu_transcoder/ (Ville) v3: - Define flags to look like separate bits instead of the values of the same bitfield. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120092325.21249-2-imre.deak@intel.com
2018-11-09drm/i915/psr: Move intel_psr_disable_source() code to intel_psr_disable_locked()José Roberto de Souza1-16/+9
In the past we had hooks to configure HW for VLV/CHV too, in the drop of VLV/CHV support the intel_psr_disable_source() code was not moved to the caller, so doing it here. Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-4-jose.souza@intel.com
2018-11-09drm/i915/psr: Always wait for idle state when disabling PSRJosé Roberto de Souza1-23/+18
It should always wait for idle state when disabling PSR because PSR could be inactive due a call to intel_psr_exit() and while PSR is still being disabled asynchronously userspace could change the modeset causing a call to psr_disable() that will not wait for PSR idle and then PSR will be enabled again while PSR is still not idle. v2: rebased on top of the patch reusing psr_exit() Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-2-jose.souza@intel.com
2018-11-09drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()José Roberto de Souza1-29/+21
Both functions have the same code to disable PSR, so let's reuse that code instead of duplicate. Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-1-jose.souza@intel.com
2018-10-29drm/i915: Prefer IS_GEN<n> check with bitmask.Rodrigo Vivi1-1/+1
Whenever possible we should stick with IS_GEN<n> checks. Bitmaks has been introduced on commit ae7617f0ef18 ("drm/i915: Allow optimized platform checks") for efficiency. Let's stick with it whenever possible. This patch was generated with coccinelle: spatch -sp_file is_gen.cocci *{c,h} --in-place is_gen.cocci: @gen2@ expression e; @@ -INTEL_GEN(e) == 2 +IS_GEN2(e) @gen3@ expression e; @@ -INTEL_GEN(e) == 3 +IS_GEN3(e) @gen4@ expression e; @@ -INTEL_GEN(e) == 4 +IS_GEN4(e) @gen5@ expression e; @@ -INTEL_GEN(e) == 5 +IS_GEN5(e) @gen6@ expression e; @@ -INTEL_GEN(e) == 6 +IS_GEN6(e) @gen7@ expression e; @@ -INTEL_GEN(e) == 7 +IS_GEN7(e) @gen8@ expression e; @@ -INTEL_GEN(e) == 8 +IS_GEN8(e) @gen9@ expression e; @@ -INTEL_GEN(e) == 9 +IS_GEN9(e) @gen10@ expression e; @@ -INTEL_GEN(e) == 10 +IS_GEN10(e) @gen11@ expression e; @@ -INTEL_GEN(e) == 11 +IS_GEN11(e) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181026195143.20353-1-rodrigo.vivi@intel.com
2018-10-06drm/i915/psr: Use WA to force HW tracking to exit PSR2José Roberto de Souza1-14/+10
This WA also works fine for PSR2, triggering a selective update when possible. Acked-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181003205031.32474-4-jose.souza@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-06 06:33:06 +0300