summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2020-09-03drm/amdgpu/swsmu: add get_fan_parameters callbacks for smu11 asicsAlex Deucher
grab the value from the pptable. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amdgpu/swsmu: add new callback for getting fan parametersAlex Deucher
To fetch the max rpm from pptable. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amdgpu: disable gpu-sched load balance for uvdNirmoy Das
On hardware with multiple uvd instances, dependent uvd jobs may get scheduled to different uvd instances. Because uvd_enc jobs retain hw context, dependent jobs should always run on the same uvd instance. This patch disables GPU scheduler's load balancer for a context that binds jobs from the same context to a uvd instance. v2: Squash in uvd_enc fix Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/managed: Cleanup of unused functions and polishing docsDaniel Vetter
Following functions are only used internally, not by drivers: - devm_drm_dev_init Also, now that we have a very slick and polished way to allocate a drm_device with devm_drm_dev_alloc, update all the docs to reflect the new reality. Mostly this consists of deleting old and misleading hints. Two main ones: - it is no longer required that the drm_device base class is first in the structure. devm_drm_dev_alloc can cope with it being anywhere - obviously embedded now strongly recommends using devm_drm_dev_alloc v2: Fix typos (Noralf) v3: Split out the removal of drm_dev_init, that's blocked on some discussions on how to convert vgem/vkms/i915-selftests. Adjust commit message to reflect that. Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> (v2) Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200902072627.3617301-1-daniel.vetter@ffwll.ch
2020-09-03drm/i915: fix regression leading to display audio probe failure on GLKKai Vehmanen
In commit 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking to separate function") the order of force_min_cdclk_changed check and intel_modeset_checks(), was reversed. This broke the mechanism to immediately force a new CDCLK minimum, and lead to driver probe errors for display audio on GLK platform with 5.9-rc1 kernel. Fix the issue by moving intel_modeset_checks() call later. [vsyrjala: It also broke the ability of planes to bump up the cdclk and thus could lead to underruns when eg. flipping from 32bpp to 64bpp framebuffer. To be clear, we still compute the new cdclk correctly but fail to actually program it to the hardware due to intel_set_cdclk_{pre,post}_plane_update() not getting called on account of state->modeset==false.] Fixes: 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking to separate function") BugLink: https://github.com/thesofproject/linux/issues/2410 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200901151036.1312357-1-kai.vehmanen@linux.intel.com
2020-09-03drm/ttm: remove io_reserve_lru handling v3Christian König
That is not used any more. v2: keep the NULL checks in TTM. v3: remove unused variable Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/388646/
2020-09-03drm/nouveau: move io_reserve_lru handling into the driver v5Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve v3: rebased and use both base and offset in the check v4: fix small typos and test the patch v5: rebased and keep the mem.bus init in TTM. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/388643/
2020-09-03drm/ttm: make sure that we always zero init mem.bus v2Christian König
We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/388642/
2020-09-03drm/nouveau/kms/nv50-gp1xx: add WAR for EVO push buffer HW bugBen Skeggs
Thanks to NVIDIA for confirming this workaround, and clarifying which HW is affected. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Tested-by: Alexander Kapshuk <alexander.kapshuk@gmail.com>
2020-09-03drm/nouveau/kms/nv50-gp1xx: disable notifies again after core updateBen Skeggs
This was lost during the header conversion. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-09-03drm/nouveau/kms/nv50-: add some whitespace before debug messageBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-09-03drm/nouveau/kms/gv100-: Include correct push header in crcc37d.cLyude Paul
Looks like when we converted everything over to Nvidia's class headers, we mistakenly included the nvif/push507b.h instead of nvif/pushc37b.h, which resulted in breaking CRC reporting for volta+: nouveau 0000:1f:00.0: disp: chid 0 stat 10003361 reason 3 [RESERVED_METHOD] mthd 0d84 data 00000000 code 00000000 nouveau 0000:1f:00.0: disp: chid 0 stat 10003360 reason 3 [RESERVED_METHOD] mthd 0d80 data 00000000 code 00000000 nouveau 0000:1f:00.0: DRM: CRC notifier ctx for head 3 not finished after 50ms So, fix that. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: c4b27bc8682c ("drm/nouveau/kms/nv50-: convert core crc_set_src() to new push macros") Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-09-03drm/radeon: Prefer lower feedback dividersKai-Heng Feng
Commit 2e26ccb119bd ("drm/radeon: prefer lower reference dividers") fixed screen flicker for HP Compaq nx9420 but breaks other laptops like Asus X50SL. Turns out we also need to favor lower feedback dividers. Users confirmed this change fixes the regression and doesn't regress the original fix. Fixes: 2e26ccb119bd ("drm/radeon: prefer lower reference dividers") BugLink: https://bugs.launchpad.net/bugs/1791312 BugLink: https://bugs.launchpad.net/bugs/1861554 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amdgpu: Fix bug in reporting voltage for CIKSandeep Raghuraman
On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amdgpu: Specify get_argument function for ci_smu_funcsSandeep Raghuraman
Starting in Linux 5.8, the graphics and memory clock frequency were not being reported for CIK cards. This is a regression, since they were reported correctly in Linux 5.7. After investigation, I discovered that the smum_send_msg_to_smc() function, attempts to call the corresponding get_argument() function of ci_smu_funcs. However, the get_argument() function is not defined in ci_smu_funcs. This patch fixes the bug by specifying the correct get_argument() function. Fixes: a0ec225633d9f6 ("drm/amd/powerplay: unified interfaces for message issuing and response checking") Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-09-03drm/amd/pm: enable MP0 DPM for sienna_cichlidJiansong Chen
Enable MP0 clock DPM for sienna_cichlid. Signed-off-by: Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-03drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp settingEvan Quan
Normally softwareshutdowntemp should be greater than Thotspotlimit. However, on some VEGA10 ASIC, the softwareshutdowntemp is 91C while Thotspotlimit is 105C. This seems not right and may trigger some false alarms. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-09-03drm/amd/pm: fix is_dpm_running() run error on 32bit systemKevin Wang
v1: the C type "unsigned long" size is 32bit on 32bit system, it will cause code logic error, so replace it with "uint64_t". v2: remove duplicate cast operation. Signed-off-by: Kevin <kevin1.wang@amd.com> Suggest-by: Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: Jiansong Chen <Jiansong.Chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-09-02drm/i915: Clear the repeater bit on HDCP disableSean Paul
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: ee5e5e7a5e0f ("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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-3-sean@poorly.run (cherry picked from commit 2cc0c7b520bf8ea20ec42285d4e3d37b467eb7f9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-09-02drm/i915: Fix sha_text population codeSean Paul
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: ee5e5e7a5e0f ("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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-2-sean@poorly.run (cherry picked from commit 1f0882214fd0037b74f245d9be75c31516fed040) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-09-02drm/i915/display: Ensure that ret is always initialized in ↵Nathan Chancellor
icl_combo_phy_verify_state 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: 239bef676d8e ("drm/i915/display: Implement new combo phy initialization step") Link: https://github.com/ClangBuiltLinux/linux/issues/1094 Signed-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.com Signed-off-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 2034c2129bc4a91d471815d4dc7a2a69eaa5338d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-09-02drm/virtio: fix unblankGerd Hoffmann
When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. v2: use drm_atomic_crtc_needs_modeset() (Daniel). Cc: 1882851@bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Diego Viola <diego.viola@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-2-kraxel@redhat.com (cherry picked from commit 1bc371cd0ec907bab870cacb6e898105f9c41dc8)
2020-09-02drm/virtio: drop virtio_gpu_output->enabledGerd Hoffmann
Not needed, already tracked by drm_crtc_state->active. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-3-kraxel@redhat.com
2020-09-02drm/virtio: fix unblankGerd Hoffmann
When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. v2: use drm_atomic_crtc_needs_modeset() (Daniel). Cc: 1882851@bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Diego Viola <diego.viola@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-2-kraxel@redhat.com
2020-09-01drm/gma500: Constify static structsRikard Falkeborn
The only usage of these is to assign their address to the fbops field in the fb_info struct, which is a const pointer. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200830211741.17326-1-rikard.falkeborn@gmail.com
2020-09-01drm: Replace mode->export_head with a booleanVille Syrjälä
In order to shrink drm_display_mode below the magic two cacheline mark in 64bit we need to shrink it by another 8 bytes. The easiest thing to eliminate is the 'export_head' list head which is only used during the getconnector ioctl to temporarly track which modes on the connector's mode list are to be exposed and which are to remain hidden. We can simply replace the list head with a boolean which we use to tag the modes that are to be exposed. If we make sure to clear the tags after we're done with them we don't even need an extra loop over the modes to reset the tags at the start of the getconnector ioctl. Conveniently we already have a hole for the boolean left behind by the removal of mode->private_flags. The final size of the struct is now 112 bytes on 32bit and 120 bytes on 64bit. Another alternative would be a temp bitmask so we wouldn't have to have anything in the mode struct itself. The main issue is how large of a bitmask do we need? I guess we could allocate it dynamically but that means an extra kcalloc() and an extra loop through the modes to count them first (or grow the bitmask with krealloc() as needed). CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-17-ville.syrjala@linux.intel.com Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2020-09-01drm/dp_mst: Support remote i2c writesSam McNally
For DP MST outputs, the i2c device currently only supports transfers that can be implemented using remote i2c reads. Such transfers must consist of zero or more write transactions followed by one read transaction. DDC/CI commands require standalone write transactions and hence aren't supported. Since each remote i2c write is handled as a separate transfer, remote i2c writes can support transfers consisting of write transactions, where all but the last have I2C_M_STOP set. According to the DDC/CI 1.1 standard, DDC/CI commands only require a single write or read transaction in a transfer, so this is sufficient. For i2c transfers meeting the above criteria, generate and send a remote i2c write message for each transaction. Add the trivial remote i2c write reply parsing support so remote i2c write acks bubble up correctly. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/37 Signed-off-by: Sam McNally <sammc@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200727160225.1.I4e95a534de051551cd143e6cb83d4c5a9b0ad1cd@changeid
2020-09-01drm/crc-debugfs: Fix memleak in crc_control_writeDinghao Liu
When verify_crc_source() fails, source needs to be freed. However, current code is returning directly and ends up leaking memory. Fixes: d5cc15a0c66e ("drm: crc: Introduce verify_crc_source callback") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [danvet: change Fixes: tag per Laurent's review] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200819082228.26847-1-dinghao.liu@zju.edu.cn
2020-09-01drm/i915: Add HDCP 1.4 support for MST connectorsSean Paul
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
2020-09-01drm/i915: Print HDCP version info for all connectorsSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-16-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-16-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-17-sean@poorly.run #v7 Changes in v4: - Added to the set Changes in v5: -Print "No connector support" for hdcp sink capability as well (Ram) Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-17-sean@poorly.run
2020-09-01drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband messageSean Paul
Used to query whether an MST stream is encrypted or not. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-sean@poorly.run #v7 Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-16-sean@poorly.run #v8 Changes in v4: -Added to the set Changes in v5: -None Changes in v6: -Use FIELD_PREP to generate request buffer bitfields (Lyude) -Add mst selftest and dump/decode_sideband_req for QSES (Lyude) Changes in v7: -None Changes in v8: -Reverse the parsing on the hdcp_*x_device_present bits and leave breadcrumb in case this is incorrect (Anshuman) Changes in v8.5: -s/DRM_DEBUG_KMS/drm_dbg_kms/ (Lyude) Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200819143133.46232-1-sean@poorly.run
2020-09-01drm/i915: Add connector to hdcp_shim->check_link()Sean Paul
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: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-sean@poorly.run #v7 Changes in v4: -Added to the set Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-15-sean@poorly.run
2020-09-01drm/i915: Plumb port through hdcp initSean Paul
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: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-sean@poorly.run #v7 Changes in v5: -Added to the set Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-14-sean@poorly.run
2020-09-01drm/i915: Factor out HDCP shim functions from dp for use by dp_mstSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-12-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-12-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-13-sean@poorly.run #v7 Changes in v2: -None Changes in v3: -Created intel_dp_hdcp.c for the shared functions to live (Ville) Changes in v4: -Rebased on new drm logging change Changes in v5: -None Changes in v6: -None Changes in v7: -Rebased patch Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-13-sean@poorly.run
2020-09-01drm/i915: Use ddi_update_pipe in intel_dp_mstSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-11-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-11-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-12-sean@poorly.run #v7 Changes in v2: -None Changes in v3: -None Changes in v4: -None Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-12-sean@poorly.run
2020-09-01drm/i915: Support DP MST in enc_to_dig_port() functionSean Paul
Although DP_MST fake encoders are not subclassed from digital ports, they are associated with them. Support these encoders. Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-10-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-10-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-11-sean@poorly.run #v7 Changes in v2: -None Changes in v3: -None Changes in v4: -None Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-11-sean@poorly.run
2020-09-01drm/i915: Don't fully disable HDCP on a port if multiple pipes are using itSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-sean@poorly.run #v7 Changes in v2: -Move the toggle_signalling call into _intel_hdcp_disable so it's called from check_work Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Split minor intel_hdcp_disable refactor into separate patch (Ramalingam) Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-10-sean@poorly.run
2020-09-01drm/i915: Clean up intel_hdcp_disableSean Paul
Add an out label and un-indent hdcp disable in preparation for hdcp_mutex. No functional changes Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-9-sean@poorly.run #v7 Changes in v7: -Split into separate patch (Ramalingam) Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-9-sean@poorly.run
2020-09-01drm/i915: Protect workers against disappearing connectorsSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-8-sean@poorly.run #v7 Changes in v2: -Added to the set Changes in v3: -Change the WARN_ON condition in intel_hdcp_cleanup to allow for initializing connectors as well Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-8-sean@poorly.run
2020-09-01drm/i915: Factor out hdcp->value assignmentsSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-7-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-7-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-7-sean@poorly.run #v7 Changes in v2: -None Changes in v3: -None Changes in v4: -Rebased on top of drm_* logging changes Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-7-sean@poorly.run
2020-09-01drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signallingSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-sean@poorly.run #v7 Changes in v2: -Added to the set Changes in v3: -s/hdcp/hdmi/ in commit msg (Ram) Changes in v4: -Rebased on intel_de_(read|write) change Changes in v5: -Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0 Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-6-sean@poorly.run
2020-09-01drm/i915: Intercept Aksv writes in the aux hooksSean Paul
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-5-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-5-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-5-sean@poorly.run #v7 Changes in v2: -Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville) -Bundle Aksv if statement together (Ville) -Rename 'txbuf' to 'aksv' (Ville) Changes in v3: -None Changes in v4: -None Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-5-sean@poorly.run
2020-09-01drm/i915: WARN if HDCP signalling is enabled upon disableSean Paul
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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-4-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-4-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-4-sean@poorly.run #v7 Changes in v2: -Added to the set in lieu of just clearing the bit Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Rebased, variable name changed from 'ctl' to 'val' Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-4-sean@poorly.run
2020-09-01drm/i915: Clear the repeater bit on HDCP disableSean Paul
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: ee5e5e7a5e0f ("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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-sean@poorly.run #v7 Changes in v2: -Added to the set Changes in v3: -None I had previously agreed that clearing the rep_ctl bits on enable would also be a good idea. However when I committed that idea to code, it didn't look right. So let's rely on enables and disables being paired and everything outside of that will be considered a bug Changes in v4: -s/I915_(READ|WRITE)/intel_de_(read|write)/ Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-3-sean@poorly.run
2020-09-01drm/i915: Fix sha_text population codeSean Paul
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: ee5e5e7a5e0f ("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: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-sean@poorly.run #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-sean@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-sean@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-2-sean@poorly.run #v7 Changes in v2: -None Changes in v3: -None Changes in v4: -Rebased on intel_de_write changes Changes in v5: -None Changes in v6: -None Changes in v7: -None Changes in v8: -None Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-2-sean@poorly.run
2020-08-31drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()Lyude Paul
Now that we've extracted i915's code for reading both the normal DPCD caps and extended DPCD caps into a shared helper, let's start using this in nouveau to enable us to start checking extended DPCD caps for free. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-21-lyude@redhat.com
2020-08-31drm/i915/dp: Extract drm_dp_read_dpcd_caps()Lyude Paul
Since DP 1.3, it's been possible for DP receivers to specify an additional set of DPCD capabilities, which can take precedence over the capabilities reported at DP_DPCD_REV. Basically any device supporting DP is going to need to read these in an identical manner, in particular nouveau, so let's go ahead and just move this code out of i915 into a shared DRM DP helper that we can use in other drivers. v2: * Remove redundant dpcd[DP_DPCD_REV] == 0 check * Fix drm_dp_dpcd_read() ret checks Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-20-lyude@redhat.com
2020-08-31drm/nouveau/kms: Don't change EDID when it hasn't actually changedLyude Paul
Currently in nouveau_connector_ddc_detect() and nouveau_connector_detect_lvds(), we start the connector probing process by releasing the previous EDID and informing DRM of the change. However, since commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") drm_connector_update_edid_property() actually checks whether the new EDID we've specified is different from the previous one, and updates the connector's epoch accordingly if it is. But, because we always set the EDID to NULL first in nouveau_connector_ddc_detect() and nouveau_connector_detect_lvds() we end up making DRM think that the EDID changes every single time we do a connector probe - which isn't needed. So, let's fix this by not clearing the EDID at the start of the connector probing process, and instead simply changing or removing it once near the end of the probing process. This will help prevent us from sending unneeded hotplug events to userspace when nothing has actually changed. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-19-lyude@redhat.com
2020-08-31drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNTLyude Paul
This is another bit that we never implemented for nouveau: dongle detection. When a "dongle", e.g. an active display adaptor, is hooked up to the system and causes an HPD to be fired, we don't actually know whether or not there's anything plugged into the dongle without checking the sink count. As a result, plugging in a dongle without anything plugged into it currently results in a bogus EDID retrieval error in the kernel log. Additionally, most dongles won't send another long HPD signal if the user suddenly plugs something in, they'll only send a short HPD IRQ with the expectation that the source will check the sink count and reprobe the connector if it's changed - something we don't actually do. As a result, nothing will happen if the user plugs the dongle in before plugging something into the dongle. So, let's fix this by checking the sink count in both nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing the connector if things change. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-18-lyude@redhat.com
2020-08-31drm/i915/dp: Extract drm_dp_read_sink_count()Lyude Paul
And of course, we'll also need to read the sink count from other drivers as well if we're checking whether or not it's supported. So, let's extract the code for this into another helper. v2: * Fix drm_dp_dpcd_readb() ret check * Add back comment and move back sink_count assignment in intel_dp_get_dpcd() v5: * Change name from drm_dp_get_sink_count() to drm_dp_read_sink_count() * Also, add "See also:" section to kdocs Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-17-lyude@redhat.com
generated by cgit (git 2.34.1) at 2025-09-14 18:26:45 +0000