aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2020-09-07drm/i915: Skip taking acquire mutex for no ref->active callbackChris Wilson1-8/+16
If no active callback is defined for i915_active, we do not need to serialise its enabling with the mutex. We still do only want to call the debug activate once, and must still serialise with a concurrent retire. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/selftests: Drop stale timeline constructor assertChris Wilson1-1/+0
Since we pass around encoded parameters to the kernel context constructor using the ce->timeline pointer, we can no longer assert that it should be zero for mock timeline construction. Fixes: d1bf5dd8f6d5 ("drm/i915/gt: Support multiple pinned timelines") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> [Joonas: Updated Fixes: link after rebasing and reordering into drm-intel-gt-next branch] Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/gt: Pull release of node->age under the spinlockChris Wilson1-1/+1
We need to ensure that the list is valid prior to marking the node as retrievable, otherwise we may see two threads compete over the same node in intel_gt_get_buffer_pool(). If the first thread acquires and releases the node in the same jiffie, the second thread may then acquire it (as the jiffie now again matches the expected value) and claim the node before it is put back into the list. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/gt: Support multiple pinned timelinesChris Wilson8-23/+61
We may need to allocate more than one pinned context/timeline for each engine which can utilise the per-engine HWSP, so we need to give each a different offset within it. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/gem: Delay tracking the GEM context until it is registeredChris Wilson1-5/+11
Avoid exposing a partially constructed context by deferring the list_add() from the initial construction to the end of registration. Otherwise, if we peek into the list of contexts from inside debugfs, we may see the partially constructed context and chase down some dangling incomplete pointers. Reported-by: CQ Tang <[email protected]> Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace") References: f6e8aa387171 ("drm/i915: Report the number of closed vma held by each context in debugfs") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: CQ Tang <[email protected]> Cc: <[email protected]> # v5.2+ Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/gt: Fix termination condition for freeing all buffer objectsChris Wilson1-5/+8
A last minute change, that unfortunately broke CI so badly it declared SUCCESS, was to refactor the debug free all buffer pool code to reuse the normal worker, inverted the termination condition so that it instead of discarding the nodes, they were all declared young enough and eligible for reuse. Fixes: 06b73c2d0b65 ("drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> [Joonas: Updating Fixes: link after rebasing and reordering into drm-intel-gt-next] Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/selftests: Flush the active barriers before assertingChris Wilson1-0/+2
Before we peek at the barrier status for an assert, first serialise with its callbacks so that we see a stable value. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/gt: Delay taking the spinlock for grabbing from the buffer poolChris Wilson2-42/+64
Some very low hanging fruit, but contention on the pool->lock is noticeable between intel_gt_get_buffer_pool() and pool_retire(), with the majority of the hold time due to the locked list iteration. If we make the node itself RCU protected, we can perform the search for an suitable node just under RCU, reserving taking the lock itself for claiming the node and manipulating the list. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/gt: Disable preparser around xcs invalidations on tglChris Wilson1-2/+13
Unlike rcs where we have conclusive evidence from our selftesting that disabling the preparser before performing the TLB invalidate and relocations does impact upon the GPU execution, the evidence for the same requirement on xcs is much more circumstantial. Let's apply the preparser disable between batches as we invalidate the TLB as a dose of healthy paranoia, just in case. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2169 Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/gem: Remove disordered per-file request list for throttlingChris Wilson8-85/+50
I915_GEM_THROTTLE dates back to the time before contexts where there was just a single engine, and therefore a single timeline and request list globally. That request list was in execution/retirement order, and so walking it to find a particular aged request made sense and could be split per file. That is no more. We now have many timelines with a file, as many as the user wants to construct (essentially per-engine, per-context). Each of those run independently and so make the single list futile. Remove the disordered list, and iterate over all the timelines to find a request to wait on in each to satisfy the criteria that the CPU is no more than 20ms ahead of its oldest request. It should go without saying that the I915_GEM_THROTTLE ioctl is no longer used as the primary means of throttling, so it makes sense to push the complication into the ioctl where it only impacts upon its few irregular users, rather than the execbuf/retire where everybody has to pay the cost. Fortunately, the few users do not create vast amount of contexts, so the loops over contexts/engines should be concise. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915: Soften the tasklet flush frequency before waitsChris Wilson1-2/+18
We include a tasklet flush before waiting on a request as a precaution against the HW being lax in event signaling. We now have a precautionary flush in the engine's heartbeat and so do not need to be quite so zealous on every request wait. If we focus on the request, the only tasklet flush that matters is if there is a delay in submitting this request to HW, so if the request is not ready to be executed, no advantage in reducing this wait can be gained by running the tasklet. And there is little point in doing busy work for no result. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915/selftests: Mock the status_page.vma for the kernel_contextChris Wilson1-0/+3
Since we assert that the kernel_context is using the perma-pinned HWSP, make it so. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2179 Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-07drm/i915: Reduce i915_request.lock contention for i915_request_waitChris Wilson1-10/+8
Currently, we use i915_request_completed() directly in i915_request_wait() and follow up with a manual invocation of dma_fence_signal(). This appears to cause a large number of contentions on i915_request.lock as when the process is woken up after the fence is signaled by an interrupt, we will then try and call dma_fence_signal() ourselves while the signaler is still holding the lock. dma_fence_is_signaled() has the benefit of checking the DMA_FENCE_FLAG_SIGNALED_BIT prior to calling dma_fence_signal() and so avoids most of that contention. Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]>
2020-09-06drm/i915: panel: Use atomic PWM API for devs with an external PWM controllerHans de Goede2-40/+33
Now that the PWM drivers which we use have been converted to the atomic PWM API, we can move the i915 panel code over to using the atomic PWM API. The removes a long standing FIXME and this removes a flicker where the backlight brightness would jump to 100% when i915 loads even if using the fastset path. Note that this commit also simplifies pwm_disable_backlight(), by dropping the intel_panel_actually_set_backlight(..., 0) call. This call sets the PWM to 0% duty-cycle. I believe that this call was only present as a workaround for a bug in the pwm-crc.c driver where it failed to clear the PWM_OUTPUT_ENABLE bit. This is fixed by an earlier patch in this series. After the dropping of this workaround, the usleep call, which seems unnecessary to begin with, has no useful effect anymore, so drop that too. Acked-by: Jani Nikula <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-06drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM ↵Hans de Goede1-3/+4
controller So far for devices using an external PWM controller (devices using pwm_setup_backlight()), we have been hardcoding the minimum allowed PWM level to 0. But several of these devices specify a non 0 minimum setting in their VBT. Change pwm_setup_backlight() to use get_backlight_min_vbt() to get the minimum level. Acked-by: Jani Nikula <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-06drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM ↵Hans de Goede2-8/+12
controller So far for devices using an external PWM controller (devices using pwm_setup_backlight()), we have been hardcoding the period-time passed to pwm_config() to 21333 ns. I suspect this was done because many VBTs set the PWM frequency to 200 which corresponds to a period-time of 5000000 ns, which greatly exceeds the PWM_MAX_PERIOD_NS define in the Crystal Cove PMIC PWM driver, which used to be 21333. This PWM_MAX_PERIOD_NS define was actually based on a bug in the PWM driver where its period and duty-cycle times where off by a factor of 256. Due to this bug the hardcoded CRC_PMIC_PWM_PERIOD_NS value of 21333 would result in the PWM driver using its divider of 128, which would result in a PWM output frequency of 6000000 Hz / 256 / 128 = 183 Hz. So actually pretty close to the default VBT value of 200 Hz. Now that this bug in the pwm-crc driver is fixed, we can actually use the VBT defined frequency. This is important because: a) With the pwm-crc driver fixed it will now translate the hardcoded CRC_PMIC_PWM_PERIOD_NS value of 21333 ns / 46 Khz to a PWM output frequency of 23 KHz (the max it can do). b) The pwm-lpss driver used on many models has always honored the 21333 ns / 46 Khz request Some panels do not like such high output frequencies. E.g. on a Terra Pad 1061 tablet, using the LPSS PWM controller, the backlight would go from off to max, when changing the sysfs backlight brightness value from 90-100%, anything under aprox. 90% would turn the backlight fully off. Honoring the VBT specified PWM frequency will also hopefully fix the various bug reports which we have received about users perceiving the backlight to flicker after a suspend/resume cycle. Acked-by: Jani Nikula <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-06drm/i915: panel: Add get_vbt_pwm_freq() helperHans de Goede1-10/+17
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency out of get_backlight_max_vbt(). This is a preparation patch for honering the VBT PWM frequency for devices which use an external PWM controller (devices using pwm_setup_backlight()). Acked-by: Jani Nikula <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-04Merge tag 'drm-fixes-2020-09-04' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2-8/+28
Pull drm fixes from Dave Airlie: "Not much going on this week, nouveau has a display hw bug workaround, amdgpu has some PM fixes and CIK regression fixes, one single radeon PLL fix, and a couple of i915 display fixes. amdgpu: - Fix for 32bit systems - SW CTF fix - Update for Sienna Cichlid - CIK bug fixes radeon: - PLL fix i915: - Clang build warning fix - HDCP fixes nouveau: - display fixes" * tag 'drm-fixes-2020-09-04' of git://anongit.freedesktop.org/drm/drm: drm/nouveau/kms/nv50-gp1xx: add WAR for EVO push buffer HW bug drm/nouveau/kms/nv50-gp1xx: disable notifies again after core update drm/nouveau/kms/nv50-: add some whitespace before debug message drm/nouveau/kms/gv100-: Include correct push header in crcc37d.c drm/radeon: Prefer lower feedback dividers drm/amdgpu: Fix bug in reporting voltage for CIK drm/amdgpu: Specify get_argument function for ci_smu_funcs drm/amd/pm: enable MP0 DPM for sienna_cichlid drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting drm/amd/pm: fix is_dpm_running() run error on 32bit system drm/i915: Clear the repeater bit on HDCP disable drm/i915: Fix sha_text population code drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
2020-09-04Merge branch 'simplify-do_wp_page'Linus Torvalds1-8/+0
Merge emailed patches from Peter Xu: "This is a small series that I picked up from Linus's suggestion to simplify cow handling (and also make it more strict) by checking against page refcounts rather than mapcounts. This makes uffd-wp work again (verified by running upmapsort)" Note: this is horrendously bad timing, and making this kind of fundamental vm change after -rc3 is not at all how things should work. The saving grace is that it really is a a nice simplification: 8 files changed, 29 insertions(+), 120 deletions(-) The reason for the bad timing is that it turns out that commit 17839856fd58 ("gup: document and work around 'COW can break either way' issue" broke not just UFFD functionality (as Peter noticed), but Mikulas Patocka also reports that it caused issues for strace when running in a DAX environment with ext4 on a persistent memory setup. And we can't just revert that commit without re-introducing the original issue that is a potential security hole, so making COW stricter (and in the process much simpler) is a step to then undoing the forced COW that broke other uses. Link: https://lore.kernel.org/lkml/alpine.LRH.2.02.2009031328040.6929@file01.intranet.prod.int.rdu2.redhat.com/ * emailed patches from Peter Xu <[email protected]>: mm: Add PGREUSE counter mm/gup: Remove enfornced COW mechanism mm/ksm: Remove reuse_ksm_page() mm: do_wp_page() simplification
2020-09-04mm/gup: Remove enfornced COW mechanismPeter Xu1-8/+0
With the more strict (but greatly simplified) page reuse logic in do_wp_page(), we can safely go back to the world where cow is not enforced with writes. This essentially reverts commit 17839856fd58 ("gup: document and work around 'COW can break either way' issue"). There are some context differences due to some changes later on around it: 2170ecfa7688 ("drm/i915: convert get_user_pages() --> pin_user_pages()", 2020-06-03) 376a34efa4ee ("mm/gup: refactor and de-duplicate gup_fast() code", 2020-06-03) Some lines moved back and forth with those, but this revert patch should have striped out and covered all the enforced cow bits anyways. Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-09-04drm/i915: remove the extra modeset init layerJani Nikula1-43/+21
Streamline the modeset init by removing the extra init layer. No functional changes, which means the cleanup path looks hideous. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/62c32c35683b843ecdc2eca2bd2d3e62cb705e96.1599056955.git.jani.nikula@intel.com
2020-09-04drm/i915: split out intel_modeset_driver_remove_nogem() and simplifyJani Nikula3-21/+16
Split out a separate display function for driver remove after gem deinitialization. Note that the sequence is not symmetric with init. However use similar naming as that reflects the deinit sequence. No functional changes. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/197fa7e488b412e147ff0fe9440c48811888f1a6.1599056955.git.jani.nikula@intel.com
2020-09-04drm/i915: move more display related probe to intel_modeset_init_noirq()Jani Nikula2-38/+35
With the intel_modeset_* probe functions clarified, we can continue with moving more related calls to the right layer: - drm_vblank_init() - intel_bios_init() - intel_vga_register() - intel_csr_ucode_init() Unfortunately, for the time being, we also need to move a call to the *wrong* layer: the power domain init. No functional changes. v2: move probe failure while at it, power domain init Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/da229ffbed64983f002605074533c8b2878d17ee.1599056955.git.jani.nikula@intel.com
2020-09-04drm/i915: split intel_modeset_init() pre/post gem initJani Nikula3-17/+29
Turn current intel_modeset_init() to a pre-gem init function, and add a new intel_modeset_init() function and move all post-gem modeset init there, in the correct layer. No functional changes. Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/5f4603f2c0216dba980338f00e0bfa791b526231.1599056955.git.jani.nikula@intel.com
2020-09-03drm/i915: fix regression leading to display audio probe failure on GLKKai Vehmanen1-6/+4
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 <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-02drm/i915: Clear the repeater bit on HDCP disableSean Paul1-0/+6
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 <[email protected]> Cc: Ramalingam C <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sean Paul <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.17+ Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Signed-off-by: Ramalingam C <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2cc0c7b520bf8ea20ec42285d4e3d37b467eb7f9) Signed-off-by: Jani Nikula <[email protected]>
2020-09-02drm/i915: Fix sha_text population codeSean Paul1-6/+20
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 <[email protected]> Cc: Ramalingam C <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sean Paul <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.17+ Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Signed-off-by: Ramalingam C <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1f0882214fd0037b74f245d9be75c31516fed040) Signed-off-by: Jani Nikula <[email protected]>
2020-09-02drm/i915/display: Ensure that ret is always initialized in ↵Nathan Chancellor1-2/+2
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 <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: José Roberto de Souza <[email protected]> (cherry picked from commit 2034c2129bc4a91d471815d4dc7a2a69eaa5338d) Signed-off-by: Jani Nikula <[email protected]>
2020-09-01drm/i915: Add HDCP 1.4 support for MST connectorsSean Paul3-2/+84
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 <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Print HDCP version info for all connectorsSean Paul1-12/+9
De-duplicate the HDCP version code for each connector and print it for all connectors. Cc: Juston Li <[email protected]> Cc: Ramalingam C <[email protected]> Reviewed-by: Juston Li <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Add connector to hdcp_shim->check_link()Sean Paul4-8/+10
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 <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Plumb port through hdcp initSean Paul4-8/+10
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ä <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Factor out HDCP shim functions from dp for use by dp_mstSean Paul4-606/+642
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 <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Use ddi_update_pipe in intel_dp_mstSean Paul3-5/+13
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 <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Support DP MST in enc_to_dig_port() functionSean Paul1-7/+14
Although DP_MST fake encoders are not subclassed from digital ports, they are associated with them. Support these encoders. Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Don't fully disable HDCP on a port if multiple pipes are using itSean Paul5-0/+45
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 <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Clean up intel_hdcp_disableSean Paul1-9/+10
Add an out label and un-indent hdcp disable in preparation for hdcp_mutex. No functional changes Reviewed-by: Anshuman Gupta <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v7 Changes in v7: -Split into separate patch (Ramalingam) Changes in v8: -None Signed-off-by: Ramalingam C <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Protect workers against disappearing connectorsSean Paul1-5/+39
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 <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Factor out hdcp->value assignmentsSean Paul1-21/+46
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 <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signallingSean Paul6-22/+26
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ä <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Intercept Aksv writes in the aux hooksSean Paul1-33/+29
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ä <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: WARN if HDCP signalling is enabled upon disableSean Paul1-0/+2
HDCP signalling should not be left on, WARN if it is Cc: Ville Syrjälä <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Clear the repeater bit on HDCP disableSean Paul1-0/+6
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 <[email protected]> Cc: Ramalingam C <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sean Paul <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.17+ Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/i915: Fix sha_text population codeSean Paul1-6/+20
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 <[email protected]> Cc: Ramalingam C <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sean Paul <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: [email protected] Cc: <[email protected]> # v4.17+ Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-31drm/i915/dp: Extract drm_dp_read_dpcd_caps()Lyude Paul3-60/+3
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 <[email protected]> Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-31drm/i915/dp: Extract drm_dp_read_sink_count()Lyude Paul1-6/+5
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 <[email protected]> Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-31drm/i915/dp: Extract drm_dp_read_sink_count_cap()Lyude Paul1-9/+12
Since other drivers are also going to need to be aware of the sink count in order to do proper dongle detection, we might as well steal i915's DP_SINK_COUNT helpers and move them into DRM helpers so that other dirvers can use them as well. Note that this also starts using intel_dp_has_sink_count() in intel_dp_detect_dpcd(), which is a functional change. v5: * Change name from drm_dp_has_sink_count() to drm_dp_read_sink_count_cap() Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-31drm/i915/dp: Extract drm_dp_read_downstream_info()Lyude Paul1-12/+2
We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_read_downstream_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before trying to read it, just to make things easier for the caller * We skip reading downstream port info if the DPCD indicates that we don't support downstream port info * We only read as many bytes as needed for the reported number of downstream ports, no sense in reading the whole thing every time v2: * Fixup logic for calculating the downstream port length to account for the fact that downstream port caps can be either 1 byte or 4 bytes long. We can actually skip fixing the max_clock/max_bpc helpers here since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway. * Fix ret code check for drm_dp_dpcd_read v5: * Change name from drm_dp_downstream_read_info() to drm_dp_read_downstream_info() * Also, add "See Also" sections for the various downstream info functions (drm_dp_read_downstream_info(), drm_dp_downstream_max_clock(), drm_dp_downstream_max_bpc()) Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-31drm/i915/dp: Extract drm_dp_read_mst_cap()Lyude Paul1-16/+2
Just a tiny drive-by cleanup, we can consolidate i915's code for checking for MST support into a helper to be shared across drivers. v5: * Drop !!() * Move drm_dp_has_mst() out of header * Change name from drm_dp_has_mst() to drm_dp_read_mst_cap() Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Sean Paul <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-28drm/i915/display: Ensure that ret is always initialized in ↵Nathan Chancellor1-2/+2
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 <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: José Roberto de Souza <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.