- 17 Jan, 2020 4 commits
-
-
Lyude Paul authored
For eDP panels, it appears it's expected that so long as the panel is in DPCD control mode that the brightness value is never set to 0. Instead, if the desired effect is to set the panel's backlight to 0 we're expected to simply turn off the backlight through the DP_EDP_DISPLAY_CONTROL_REGISTER. We already do the latter correctly in intel_dp_aux_disable_backlight(). But, we make the mistake of writing the DPCD registers in the wrong order when enabling the backlight in intel_dp_aux_enable_backlight() since we currently enable the backlight through DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On the X1 Extreme 2nd Generation, this appears to have the potential of confusing the panel in such a way that further attempts to set the brightness don't actually change the backlight as expected and leave it off. Presumably, this happens because the incorrect register writing order briefly leaves the panel with DPCD mode enabled and a 0 brightness level set. So, reverse the order we write the DPCD registers when enabling the panel backlight so that we write the brightness value first, and enable the backlight second. This fix appears to be the final bit needed to get the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen working. Tested-by:
AceLan Kao <acelan.kao@canonical.com> Tested-by:
Perry Yuan <pyuan@redhat.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-4-lyude@redhat.com
-
Lyude Paul authored
Currently we always determine the initial panel brightness level by simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This seems wrong though, because if the panel is not currently in DPCD control mode there's not really any reason why there would be any brightness value programmed in the first place. This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd Generation, where the default value in these registers is always 0 on boot despite the fact the panel runs at max brightness by default. Getting the initial brightness value correct here is important as well, since the panel on this laptop doesn't behave well if it's ever put into DPCD control mode while the brightness level is programmed to 0. So, let's fix this by checking what the current backlight control mode is before reading the brightness level. If it's in DPCD control mode, we return the programmed brightness level. Otherwise we assume 100% brightness and return the highest possible brightness level. This also prevents us from accidentally programming a brightness level of 0. This is one of the many fixes that gets backlight controls working on the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen. Changes since v1: * s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/ - Jani Tested-by:
-
Lyude Paul authored
Max backlight value for the panel was being calculated using byte count i.e. 0xffff if 2 bytes are supported for backlight brightness and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT determines the number of active control bits used for the brightness setting. Thus, even if the panel uses 2 byte setting, it might not use all the control bits. Thus, max backlight should be set based on the value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255. Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT frequency which results in a different max backlight value. Thus, setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of enable so that max backlight can be calculated correctly. Only the frequency divider is set during the enable phase using the value of EDP_PWMGEN_BIT_COUNT. This is based off the original patch series from Furquan Shaikh <furquan@google.com>: https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3 Changes since original patch: * Remove unused intel_dp variable in intel_dp_aux_setup_backlight() * Fix checkpatch issues * Make sure that we rewrite the pwmgen bit count whenever we bring the panel out of D3 mode v2 by Jani: * rebase * fix readb return value check Cc: Furquan Shaikh <furquan@google.com> Tested-by:
-
Vivek Kasireddy authored
Perform the i2c bus/adapter lookup from ACPI Namespace only if ACPI is enabled in the kernel config. If ACPI is not enabled or if the lookup fails, we'll fallback to using the VBT for identifying the i2c bus. v2: Add fixes tag (Jani) Fixes: 8cbf89db ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)") Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
- 16 Jan, 2020 7 commits
-
-
Chris Wilson authored
Currently, we skip error capture upon forced preemption. We apply forced preemption when there is a higher priority request that should be running but is being blocked, and we skip inline error capture so that the preemption request is not further delayed by a user controlled capture -- extending the denial of service. However, preemption reset is also used for heartbeats and regular GPU hangs. By skipping the error capture, we remove the ability to debug GPU hangs. In order to capture the error without delaying the preemption request further, we can do an out-of-line capture by removing the guilty request from the execution queue and scheduling a worker to dump that request. When removing a request, we need to remove the entire context and all descendants from the execution queue, so that they do not jump past. Closes: https://gitlab.freedesktop.org/drm/intel/issues/738 Fixes: 3a7a92ab ("drm/i915/execlists: Force preemption") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
In order to support out-of-line error capture, we need to remove the active request from HW and put it to one side while a worker compresses and stores all the details associated with that request. (As that compression may take an arbitrary user-controlled amount of time, we want to let the engine continue running on other workloads while the hanging request is dumped.) Not only do we need to remove the active request, but we also have to remove its context and all requests that were dependent on it (both in flight, queued and future submission). Finally once the capture is complete, we need to be able to resubmit the request and its dependents and allow them to execute. v2: Replace stack recursion with a simple list. v3: Check all the parents, not just the first, when searching for a stuck ancestor! References: https://gitlab.freedesktop.org/drm/intel/issues/738Signed-off-by:
-
Chris Wilson authored
If we keep track of when the i915_request.sched.link is on the HW runlist, or in the priority queue we can simplify our interactions with the request (such as during rescheduling). This also simplifies the next patch where we introduce a new in-between list, for requests that are ready but neither on the run list or in the queue. v2: Update i915_sched_node.link explanation for current usage where it is a link on both the queue and on the runlists. Signed-off-by:
-
José Roberto de Souza authored
Both activate functions and the dc3co disable function were doing the same thing, so better move to a function and share. Also while at it adding a WARN_ON to catch invalid values. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200113214603.52158-1-jose.souza@intel.com
-
Matt Atwood authored
The bspec tells us we need to set this bit to avoid potential underruns. v2: use new register write convention (Anshuman) add bspec 7386 ref. Bspec: 7386 Bspec: 33450 Bspec: 33451 Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
-
Chris Wilson authored
Remove the double space that crept into the fmt stringification. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116125749.2786743-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We need to allow concurrent intel_context_unpin, which means avoiding doing destructive operations like intel_ring_reset(). This was already fixed for intel_ring_unpin() in commit 0725d9a3 ("drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint"), but I overlooked that execlists_context_unpin() also made the same mistake. Reported-by:
Matthew Brost <matthew.brost@intel.com> Fixes: 84135022 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") References: 0725d9a3 ("drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint") Signed-off-by:
-
- 15 Jan, 2020 7 commits
-
-
Radhakrishna Sripada authored
Workaround database indicates we should disable VRH clockgating in pre-production hardware. V2: - Use REG_BIT macro - Update reference in commit message(Matt) Bspec: 52890 Bspec: 49424 Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add tracepoints which let us know when fbc activates/deactivates/nukes. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-5-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
fbc_supported() is just a pointless wrapper for HAS_FBC(). Get rid of it. In places where we're operating on a specific plane we can replace this with a plane->has_fbc check to avoid doing anything for crtcs that don't even support fbc. Signed-off-by:
-
Ville Syrjälä authored
Instead of dealing with the presence/absence of the primary plane in the higher level pre/post plane update code let's move all that into the fbc code itself. Now the higher level code doesn't have to think about FBC details anymore. Signed-off-by:
-
Chris Wilson authored
In converting over to using set_bit()/test_bit(), when manually inspecting the rq->fence.flags, we need to use BIT(). Fixes: e1c31fb5 ("drm/i915: Merge i915_request.flags with i915_request.fence.flags") Signed-off-by:
-
Jani Nikula authored
It's not uncommon for us to switch param types between bools and ints, often having otherwise bool semantics but -1 value for platform default. Allow bool values (such as YyNn) for ints. Reviewed-by:
-
Jani Nikula authored
Add a debugfs subdirectory i915_params with all the i915 module parameters. This is a first step, with lots of boilerplate, and not much benefit yet. This will result in a new device specific debugfs directory at /sys/kernel/debug/dri/<N>/i915_params duplicating the module specific sysfs directory at /sys/module/i915/parameters/. Going forward, all users of the parameters should use the debugfs, with the module parameters being phased out. Add debugfs permissions to I915_PARAMS_FOR_EACH(). This duplicates the mode with module parameter sysfs, but the goal is to make the module parameters read-only initial values for device specific parameters. 0 mode will bypass debugfs creation. Use it for verbose_state_checks which will need special attention in follow-up work. Reviewed-by:
-
- 14 Jan, 2020 13 commits
-
-
Matt Roper authored
I don't think we've ever hit these new error codes, but they're documented in the gen11 pcode document, so we might as well add them to the handler. Signed-off-by:
-
José Roberto de Souza authored
Renaming to match the BSpec and struct name. BSpec: 20150 Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
José Roberto de Souza authored
TGL has now a table for RBR and HBR and another table for HBR2 over combo phys. The HBR2 one has some small changes comparing to the ICL one, so adding two new tables and adding a function to return TGL combo phy tables. v2: - reordered the tgl_combo_phy_ddi_translations_dp_hbr2 to reduce diff (Matt) - removed definition of rates, kept using raw number(Jani and Ville) - changed code to use icl_get_combo_buf_trans() for non-DP as those are equal between TGL and ICL(Matt) BSpec: 49291 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
Add a i915_vma to the mock_engine/mock_ring so that the core code can always assume the presence of ring->vma. Fixes: 8ccfc20a ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by:
-
Ville Syrjälä authored
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever it is present. We copy that from the master plane to the slave plane, but we fail to copy the corresponding ggtt view. Thus when it comes time to pin the slave plane's fb we use some stale ggtt view left over from the last time the plane was used as a non-slave plane. If that previous use involved 90/270 degree rotation or remapping we'll try to shuffle the pages of the new fb around accordingingly. However the new fb may be backed by a bo with less pages than what the ggtt view rotation/remapped info requires, and so we we trip a GEM_BUG(). Steps to reproduce on icl: 1. plane 1: whatever plane 6: largish !NV12 fb + 90 degree rotation 2. plane 1: smallish NV12 fb plane 6: make invisible so it gets slaved to plane 1 3. GEM_BUG() Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/951 Fixes: 1f594b20 ("drm/i915: Remove special case slave handling during hw programming, v3.") Signed-off-by:
-
Chris Wilson authored
Take and hold a reference to each of the vma (and their objects) as we process them with the cmdparser. This stops them being freed during the work if the GEM execbuf is interrupted and the request we expected to keep the objects alive is incomplete. Fixes: 686c7c35 ("drm/i915/gem: Asynchronous cmdparser") Closes: https://gitlab.freedesktop.org/drm/intel/issues/970Signed-off-by:
-
Michal Wajdeczko authored
While we have function that returns "next fence" that can be used by new CT request, we internally store value of the last used fence. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Update GuC CTB action helpers to benefit from new CT_ERROR macro. Signed-off-by:
-
Michal Wajdeczko authored
We should start using dev variants of error logging and to simplify that introduce helper macro that will do any necessary conversions to obtain pointer to device struct. Signed-off-by:
-
Michal Wajdeczko authored
We need CT message size in bytes so just use that in helper var. Signed-off-by:
-
Chris Wilson authored
On suspend, the rc6 residency counters (stored in HW registers) will be lost and cleared. However, we keep track of the rc6 residency to provide a continuous 64b sampling, and if we see the HW value go backwards, we assume it overflowed and add on 32b/40b -- an interesting artifact when sampling across suspend. Signed-off-by:
-
Chris Wilson authored
The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we start measuruing I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from 0 and then upon first activity (park/unpark) add in all the rc6 residency since boot. After the first park with the sampler engaged, the sleep/active counters are aligned. v2: With a wakeref to be sure Closes: https://gitlab.freedesktop.org/drm/intel/issues/973 Fixes: df6a4205 ("drm/i915/pmu: Ensure monotonic rc6") Signed-off-by:
-
Jani Nikula authored
Signed-off-by:
-
- 13 Jan, 2020 8 commits
-
-
Chris Wilson authored
Currently, we reset the timer after a pre-eemption event. This has the side-effect that the timeslice runs into the second context after the first is completed after a normal promotion event, causing the second context to be swapped out early and switched for a third context. To be more fair, we want to reset the clock after promotion as well. Signed-off-by:
-
Zhang Xiaoxu authored
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there is an error when compile the kernel: drivers/gpu/drm/i915/gt/intel_reset.c: In function intel_gt_handle_error: drivers/gpu/drm/i915/gt/intel_reset.c:1233:3: error: too few arguments to function i915_capture_error_state i915_capture_error_state(gt->i915); ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./drivers/gpu/drm/i915/i915_drv.h:97:0, from ./drivers/gpu/drm/i915/display/intel_display_types.h:46, from drivers/gpu/drm/i915/gt/intel_reset.c:10: ./drivers/gpu/drm/i915/i915_gpu_error.h:267:20: note: declared here static inline void i915_capture_error_state(struct drm_i915_private *dev_priv, Fixes: 742379c0 ("drm/i915: Start chopping up the GPU error capture") Reported-by:Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by:
-
Zhang Xiaoxu authored
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there are some errors like: drivers/gpu/drm/i915/i915_irq.o: In function `i915_vma_capture_finish': ./drivers/gpu/drm/i915/i915_gpu_error.h:312: multiple definition of `i915_vma_capture_finish' drivers/gpu/drm/i915/i915_drv.o: ./drivers/gpu/drm/i915/i915_gpu_error.h:312: first defined here So, add 'static inline' on the defineation of the 'i915_vma_capture_finish' Fixes: d713e3ab("drm/i915: Correct typo in i915_vma_compress_finish stub") Reported-by:
-
Ville Syrjälä authored
Just use the passed in encoder instead of digging it out via the legacy drm_connector->encoder pointer (which we'll want to stop using). Signed-off-by:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
Lots of enc_to_foo(&encoder->base) around. Simplify by passing in the intel_encoder instead. @find@ identifier F =~ "^enc_to_.*"; identifier E; @@ F(struct drm_encoder *E) { ... } @@ identifier find.F; identifier find.E; @@ F( - struct drm_encoder *E + struct intel_encoder *encoder ) { <... - E + &encoder->base ...> } @@ identifier find.F; expression E; @@ - F(E) + F(to_intel_encoder(E)) @@ expression E; @@ - to_intel_encoder(&E->base) + E Signed-off-by:Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Life is usually easier when we pass around intel_ types instead of drm_ types. In this case it might not be, but I think being consistent is a good thing anyway. Also some of this might get cleaned up a bit more later as we keep propagating the intel_ types further. @find@ identifier F =~ "^intel_attached_.*"; identifier C; @@ F(struct drm_connector *C) { ... } @@ identifier find.F; identifier find.C; @@ F( - struct drm_connector *C + struct intel_connector *connector ) { <... - C + &connector->base ...> } @@ identifier find.F; expression C; @@ - F(C) + F(to_intel_connector(C)) @@ expression C; @@ - to_intel_connector(&C->base) + C Signed-off-by:Mika Kahola <mika.kahola@intel.com>
-
Stanislav Lisovskiy authored
There seems to be some undocumented bandwidth bottleneck/dependency which scales with CDCLK, causing FIFO underruns when CDCLK is too low, even when it's correct from BSpec point of view. Currently for TGL platforms we calculate min_cdclk initially based on pixel_rate divided by 2, accounting for also plane requirements, however in some cases the lowest possible CDCLK doesn't work and causing the underruns. We've found experimentally that raising cdclk to at least pixel_rate (rather than pixel_rate/2) eliminates these underruns, so let's use this as a temporary workaround until the hardware team can suggest a more precise remedy. Explicitly stating here that this seems to be currently rather a Hack, than final solution. v2: Use clamp operation instead of min(Matt Roper) v3: - Fixed commit message(Matt Roper) - Now using pixel_rate instead of max_cdclk(Jani Nikula) - Switched to max from clamp(Ville Syrjälä) Hopefully this hybrid satisfies everyone :) Reviewed-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/402Signed-off-by:
-
Tvrtko Ursulin authored
We use PCI device path in the registered PMU name in order to distinguish between multiple GPUs. But since tools/perf reserves a special meaning to dash and colon characters we need to transliterate them to something else. We choose an underscore. v2: * Use strreplace. (Chris) * Dashes are not good either. (Chris) Signed-off-by:
Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Fixes: 05488673 ("drm/i915/pmu: Support multiple GPUs") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Reviewed-by:
-
- 11 Jan, 2020 1 commit
-
-
Chris Wilson authored
A copy and paste error in setting up the !CONFIG_DRM_I915_CAPTURE_ERROR stubs left a conflicting duplicate declaration. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200111083007.1619228-1-chris@chris-wilson.co.uk
-
