- 01 Sep, 2020 17 commits
-
-
Sean Paul authored
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over MST. Everything except for toggling the HDCP signalling and HDCP 2.2 support is the same as the DP case, so we'll re-use those callbacks Cc: Juston Li <juston.li@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-18-sean@poorly.run #v7 Changes in v2: -Toggle HDCP from encoder disable/enable -Don't disable HDCP on MST connector destroy, leave that for encoder disable, just ensure the check_work routine isn't running any longer Changes in v3: -Place the shim in the new intel_dp_hdcp.c file (Ville) Changes in v4: -Actually use the mst shim for mst connections (Juston) -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted Changes in v5: -Add sleep on disable signalling to match hdmi delay Changes in v6: -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I don't have hardware to test it Changes in v7: -Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam) Changes in v8: -None Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-18-sean@poorly.run
-
Sean Paul authored
De-duplicate the HDCP version code for each connector and print it for all connectors. Cc: Juston Li <juston.li@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Juston Li <juston.li@intel.com> Reviewed-by:
-
Sean Paul authored
Used to query whether an MST stream is encrypted or not. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200819143133.46232-1-sean@poorly.run
-
Sean Paul authored
Currently we derive the connector from digital port in check_link(). For MST, this isn't sufficient since the digital port passed into the function can have multiple connectors downstream. This patch adds connector to the check_link() arguments so we have it when we need it. Reviewed-by:
-
Sean Paul authored
This patch plumbs port through hdcp init instead of relying on intel_attached_encoder() to return a non-NULL encoder which won't work for MST connectors. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Sean Paul authored
These functions are all the same for dp and dp_mst, so move them into a dedicated file for both sst and mst to use. Reviewed-by:
-
Sean Paul authored
In order to act upon content_protection property changes, we'll need to implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe for this Reviewed-by:
-
Sean Paul authored
Although DP_MST fake encoders are not subclassed from digital ports, they are associated with them. Support these encoders. Reviewed-by:
-
Sean Paul authored
This patch is required for HDCP over MST. If a port is being used for multiple HDCP streams, we don't want to fully disable HDCP on a port if one of them is disabled. Instead, we just disable the HDCP signalling on that particular pipe and exit early. The last pipe to disable HDCP will also bring down HDCP on the port. In order to achieve this, we need to keep a refcount in intel_digital_port and protect it using a new hdcp_mutex. Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
-
Sean Paul authored
Add an out label and un-indent hdcp disable in preparation for hdcp_mutex. No functional changes Reviewed-by:
-
Sean Paul authored
This patch adds some protection against connectors being destroyed before the HDCP workers are finished. For check_work, we do a synchronous cancel after the connector is unregistered which will ensure that it is finished before destruction. In the case of prop_work, we can't do a synchronous wait since it needs to take connection_mutex which could cause deadlock. Instead, we'll take a reference on the connector when scheduling prop_work and give it up once we're done. Reviewed-by:
-
Sean Paul authored
This is a bit of housecleaning for a future patch. Instead of sprinkling hdcp->value assignments and prop_work scheduling everywhere, introduce a function to do it for us. Reviewed-by:
-
Sean Paul authored
Instead of using intel_dig_port's encoder pipe to determine which transcoder to toggle signalling on, use the cpu_transcoder field already stored in intel_hdmi. This is particularly important for MST. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Sean Paul authored
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect aux messages and add the aksv flag in the aux transfer hook. IIRC, this was the original implementation and folks wanted this hack to be isolated to the hdcp code, which makes sense. However in testing an LG monitor on my desk, I noticed it was passing back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP auth was failing as a result. Instead of copy/pasting all of the retry logic and delays from drm dp helpers, let's just use the helpers and hide the aksv select as best as we can. Reviewed-by:
-
Sean Paul authored
HDCP signalling should not be left on, WARN if it is Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Sean Paul authored
On HDCP disable, clear the repeater bit. This ensures if we connect a non-repeater sink after a repeater, the bit is in the state we expect. Fixes: ee5e5e7a ("drm/i915: Add HDCP framework + base implementation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.17+ Reviewed-by:
-
Sean Paul authored
This patch fixes a few bugs: 1- We weren't taking into account sha_leftovers when adding multiple ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with the beginning of ksv[j] 2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was being placed on the wrong half of sha_text, overlapping the leftover ksv value 3- In the sha_leftovers == 2 case, we need to manually terminate the byte stream with 0x80 since the hardware doesn't have enough room to add it after writing M0 The upside is that all of the HDCP supported HDMI repeaters I could find on Amazon just strip HDCP anyways, so it turns out to be _really_ hard to hit any of these cases without an MST hub, which is not (yet) supported. Oh, and the sha_leftovers == 1 case works perfectly! Fixes: ee5e5e7a ("drm/i915: Add HDCP framework + base implementation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.17+ Reviewed-by:
-
- 31 Aug, 2020 1 commit
-
-
Lionel Landwerlin authored
I'll need this in IGT to identify the different kind of GTs and apply the right performance query configuration. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200828133125.157171-1-lionel.g.landwerlin@intel.com
-
- 29 Aug, 2020 1 commit
-
-
Nathan Chancellor authored
Clang warns: drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy), ^~~ drivers/gpu/drm/i915/display/intel_combo_phy.c:261:10: note: initialize the variable 'ret' to silence this warning bool ret; ^ = 0 1 warning generated. In practice, the bug this warning appears to be concerned with would not actually matter because ret gets initialized to the return value of cnl_verify_procmon_ref_values. However, that does appear to be a bug since it means the first hunk of the patch this fixes won't actually do anything (since the values of check_phy_reg won't factor into the final ret value). Initialize ret to true then make all of the assignments a bitwise AND with itself so that the function always does what it should do. Fixes: 239bef67 ("drm/i915/display: Implement new combo phy initialization step") Link: https://github.com/ClangBuiltLinux/linux/issues/1094Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200828202830.7165-1-jose.souza@intel.comSigned-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
- 28 Aug, 2020 4 commits
-
-
José Roberto de Souza authored
Update with latest tuning in the table. v3: Fix values of to last columns. BSpec: 21257 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table being used when the eDP port don't support low power voltage swing table. v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is set as EHL combo phy supports HBR3 (Matt R) Reviewed-by:
-
José Roberto de Souza authored
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table being used when the eDP port don't support low power voltage swing table. Reviewed-by:
-
José Roberto de Souza authored
TGL made stepping a litte mess, workarounds refer to the stepping of the IP(GT or Display) not of the GPU stepping so it would already require the same solution as used in commit 96c5a15f ("drm/i915/kbl: Fix revision ID checks"). But to make things even more messy it have a different IP stepping mapping between SKUs and the same stepping revision of GT do not match the same HW between TGL U/Y and regular TGL. So it was required to have 2 different macros to check GT WAs while for Display we are able to use just one macro that uses the right revids table. All TGL workarounds checked and updated accordingly. v2: - removed TODO to check if WA 14010919138 applies to regular TGL. - fixed display stepping in regular TGL (Anusha) BSpec: 52890 BSpec: 55378 BSpec: 44455 Reviewed-by:
Anusha Srivatsa <anusha.srivtsa@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Penne Lee <penne.y.lee@intel.com> Cc: Guangyao Bai <guangyao.bai@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 27 Aug, 2020 4 commits
-
-
José Roberto de Souza authored
Supported and enabled are different things so printing both. v3: using drrs->type instead of vbt.drrs_type Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Srinivas K <srinivasx.k@intel.com> Cc: Hariom Pandey <hariom.pandey@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Changes in the configuration could cause PSR to be compatible and enabled so driver must also be able to disable DRRS when doing fastsets. v2: Fixed name of DRRS compute function (Anshuman) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/173 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209 Cc: Srinivas K <srinivasx.k@intel.com> Cc: Hariom Pandey <hariom.pandey@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
José Roberto de Souza authored
DRRS and PSR can't be enable together, so giving preference to PSR as it allows more power-savings by complete shutting down display, so to guarantee this, it should compute DRRS state after compute PSR. Cc: Srinivas K <srinivasx.k@intel.com> Cc: Hariom Pandey <hariom.pandey@intel.com> Reviewed-by:
-
Colin Ian King authored
There is a spelling mistake in a drm_err message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 26 Aug, 2020 3 commits
-
-
Clint Taylor authored
Enable HW Default flip for small PL. bspec: 52890 bspec: 53508 bspec: 53273 v2: rebase to drm-tip v3: move from ctx to gt workarounds. Remove whitelist. v4: move to rcs WA init Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by:
-
Anshuman Gupta authored
HDCP code doesn't require to access power_well internal stuff, instead it should use the intel_display_power_well_is_enabled() to get the status of desired power_well. No functional change. v2: - used with_intel_runtime_pm instead of get/put. [Jani] v3: - rebased. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Anshuman Gupta authored
Currently intel_hdcp_update_pipe() is also getting called for non-hdcp connectors and get through its conditional code flow, which is completely unnecessary for non-hdcp connectors, therefore it make sense to have an early return. No functional change. v2: - rebased. Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
- 24 Aug, 2020 1 commit
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 21 Aug, 2020 1 commit
-
-
Mika Kuoppala authored
Our variety of defined gpu commands have the actual command id field and possibly length and flags applied. We did start to apply the mask during initialization of the cmd descriptors but forgot to also apply it on comparisons. Fix comparisons in order to properly deny access with associated commands. v2: fix lri with correct mask (Chris) References: 926abff2 ("drm/i915/cmdparser: Ignore Length operands during command matching") Reported-by:
Nicolai Stange <nstange@suse.de> Cc: stable@vger.kernel.org # v5.4+ Cc: Miroslav Benes <mbenes@suse.cz> Cc: Takashi Iwai <tiwai@suse.de> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200817195926.12671-1-mika.kuoppala@linux.intel.com
-
- 19 Aug, 2020 1 commit
-
-
Matt Atwood authored
Add minimum width to planes, variable with specific formats for gen11+ to reflect recent bspec changes. Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
-
- 17 Aug, 2020 7 commits
-
-
José Roberto de Souza authored
Major upgrade of HuC firmware with fixes and new features. Signed-off-by:
-
José Roberto de Souza authored
Fixes around DC5, DC6 and DC3CO in those new firmwares. Signed-off-by:
-
José Roberto de Souza authored
From the 3 WAs for PSR2 man track/selective fetch this is only one needed when doing single full frames at every flip. Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
All GEN12 platforms supports PSR2 selective fetch but not all GEN12 platforms supports PSR2 hardware tracking(aka RKL). This feature consists in software programming registers with the damaged area of each plane this way hardware will only fetch from memory those areas and sent the PSR2 selective update blocks to panel, saving even more power. But as initial step it is only enabling the full frame fetch at every flip, the actual selective fetch part will come in a future patch. Also this is only handling the page flip side, it is still completely missing frontbuffer modifications, that is why the enable_psr2_sel_fetch parameter was added. v3: - calling intel_psr2_sel_fetch_update() during the atomic check phase (Ville) BSpec: 55229 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Matt Roper authored
We usually assume that increasing PCI device revision ID's translates to newer steppings; macros like IS_KBL_REVID() that we use rely on this behavior. Unfortunately this turns out to not be true on KBL; the newer device 2 revision ID's sometimes go backward to older steppings. The situation is further complicated by different GT and display steppings associated with each revision ID. Let's work around this by providing a table to map the revision ID to specific GT and display steppings, and then perform our comparisons on the mapped values. v2: - Move the kbl_revids[] array to intel_workarounds.c to avoid compiler warnings about an unused variable in files that don't call the macros (kernel test robot). Bspec: 18329 Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Signed-off-by:
-
José Roberto de Souza authored
This new HBR2 table for TGL-U and TGL-Y is required to pass DisplayPort compliance. BSpec: 49291 Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Khaled Almahallawy<khaled.almahallawy@intel.com> Signed-off-by:
-
José Roberto de Souza authored
There is no way to differentiate TGL-U from TGL-Y by the PCI ids as some ids are available in both SKUs. So here using the root device id in the PCI bus that iGPU is in to differentiate between U and Y. BSpec: 44455 Reviewed-by:
-
