- 21 Apr, 2020 17 commits
-
-
Chris Wilson authored
Since we may lose the content of any buffer when we relinquish control of the system (e.g. suspend/resume), we have to be careful not to rely on regaining control. A good method to detect when we might be using garbage is by always injecting that garbage prior to first use on load/resume/etc. v2: Drop sanitize callback on cleanup v3: Move seqno reset to timeline enter, so we reset all timelines. However, this is done on every activation during runtime and not reset. The similar level of paranoia we apply to correcting context state after a period of inactivity. Suggested-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Venkata Ramana Nayana <venkata.ramana.nayana@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Chris Wilson authored
Let's isolate the impact of cpu frequency selection on determing the GPU throughput in response to selection of RPS frequencies. For real systems, we do have to be concerned with the impact of integrating c-states, p-states and rp-states, but for the sake of proving whether or not RPS works, one baby step at a time. For the record, as one would hope, it does not seem to impact on the measured performance, but we do it anyway to reduce the number of variables. Later, we can extend the testing to encourage the the cpu/pkg to try and sleep while the GPU is busy. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200421142236.8614-1-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/20200421142236.8614-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we detect that the RPS end points do not scale perfectly, take the time to measure all the in between values as well. We are aborting the test, so we might as well spend the available time gathering critical debug information instead. Signed-off-by:
-
Chris Wilson authored
We want to see the pstate limits whenever we fail to set the minimum frequency as that may help for debugging. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by:
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406112800.23762-14-pankaj.laxminarayan.bharadiya@intel.com
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN* calls. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON at places where struct drm_device pointer can be extracted. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON at places where struct drm_device pointer can be extracted. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN* calls. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by:
-
Pankaj Bharadiya authored
struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by:
-
Jani Nikula authored
The early check for compressed_bpp being zero is too early, as it is hit also when DSC is not enabled. Move the checks down to where the values are actually needed. This is a paranoid check for a situation that should not happen, so we don't really care about handling it gracefully apart from not oopsing. Fixes: 48b8b04c ("drm/i915/display: Enable DP Display Audio WA") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1750 Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Jani Nikula authored
Remove a number of inlines from .c files, and let the compiler decide what's best. There's more to do, but need to start somewhere, and need to start setting the example. Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Unused, hiding from the compiler warnings behind the inline keyword. Reviewed-by:
-
Matt Roper authored
AUX power wells sometimes need additional handling besides just programming the specific power well registers: * Type-C PHY's also require additional Type-C register programming * ICL combo PHY's require additional workarounds * TGL & EHL combo PHY's can be treated like any other power well Today we have dedicated aux ops for the ICL combo PHY and Type-C cases. This works fine, but means that when a new platform shows up with identical general power well handling, but different types of PHYs on its outputs, we have to define an entire new power well table for that platform and can't just re-use the table from the earlier platform -- as an example, see ehl_power_wells[], which is a subset of icl_power_wells[], *except* that we need to specify different AUX ops for the third display. If we instead create a single set of top-level aux ops that will check the PHY type and then dispatch to the appropriate handlers, we can get more reuse out of our power well definitions. This allows us to immediately eliminate ehl_power_wells[] and simply reuse the ICL table; if future platforms follow the same general power well assignments as either ICL or TGL, we'll be able to re-use those tables in the same way. Note that I've only changed ICL+ platforms over to using the new icl_aux ops; at this point it's unlikely that we'll have any new platforms that re-use gen9 or earlier power well configurations. v2: - ICL_AUX_PW_TO_PHY() won't return the proper PHY for TBT AUX power wells. But we know those wells will only used on Type-C outputs anyway, so we can just check is is_tc_tbt flag in the condition. (Jose). Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415233435.3064257-2-matthew.d.roper@intel.com
-
- 20 Apr, 2020 19 commits
-
-
Xiyu Yang authored
igt_ppgtt_pin_update() invokes i915_gem_context_get_vm_rcu(), which returns a reference of the i915_address_space object to "vm" with increased refcount. When igt_ppgtt_pin_update() returns, "vm" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in two exception handling paths of igt_ppgtt_pin_update(). When i915_gem_object_create_internal() returns IS_ERR, the refcnt increased by i915_gem_context_get_vm_rcu() is not decreased, causing a refcnt leak. Fix this issue by jumping to "out_vm" label when i915_gem_object_create_internal() returns IS_ERR. Fixes: a4e7ccda ("drm/i915: Move context management under GEM") Signed-off-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by:
Xin Tan <tanxin.ctf@gmail.com> Reviewed-by:
-
Chris Wilson authored
After having testing all the RPS controls individually, we need to take a step back and check how our RPS worker integrates them to perform dynamic GPU reclocking. So do that by submitting a spinner and wait and see what happens. Signed-off-by:
-
Chris Wilson authored
If we encounter an error while scaling, read back the frequency tables from the pcu. Signed-off-by:
-
Chris Wilson authored
Split the frequency measurement into two modes, so that we can judge the impact of the llc setup on top of the pure CS frequency scaling. Signed-off-by:
-
Chris Wilson authored
Check that the GPU does respond to our RPS frequency requests by setting our desired frequency. Signed-off-by:
-
Chris Wilson authored
If we can not manipulate the frequency with RPS, then comparing min/max power consumption is pointless / misleading. We will leave the warning about not being able to control the frequency selection via RPS to other tests so as not to confuse this more specialised check. Signed-off-by:
-
Chris Wilson authored
One of the core tenents of reclocking the GPU is that its throughput scales with the clock frequency. We can observe this by incrementing a loop counter on the GPU, and compare the different execution rates at the notional RPS frequencies. Signed-off-by:
-
Ville Syrjälä authored
We shouldn't try to do link retraining from the short hpd handler. We can't take any modeset locks there so this is racy as hell. Push the whole thing into the hotplug work like we do with SST. We'll just have to adjust the SST retraining code to deal with the MST encoders and multiple pipes. TODO: I have a feeling we should just rip this all out and do a full modeset instead. Stuff like port sync and the tgl+ MST master transcoder stuff maybe doesn't work well if we try to retrain without following the proper modeset sequence. So far haven't done any actual tests to confirm that though. Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Ville Syrjälä authored
Make intel_dp_check_mst_status() somewhat legible by humans. Note that the return value of drm_dp_mst_hpd_irq() is always either 0 or -ENOMEM, and we never did anything with the latter so we can just ignore the whole thing. We can also get rid of the direct drm_dp_mst_topology_mgr_set_mst(false) call since returning -EINVAL causes the caller to do the very same call for us. Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
Pass the encoder all the way down to intel_ddi_transcoder_func_reg_val_get(). Allows us eliminate the intel_ddi_get_crtc_encoder() eyesore. Signed-off-by:
-
Ville Syrjälä authored
Push the TRANS_DDI_FUNC_CTL into the encoder enable hook. The disable is already there, and as a followup will enable us to pass the encoder all the way down. Signed-off-by:
-
Ville Syrjälä authored
No reason that I can see why we should enable TRANS_DDI_FUNC_CTL before we set up the watermarks of configure the mbus stuff. In fact reordering these seems to match the bspec sequence better, and crucially will allow us to push the TRANS_DDI_FUNC_CTL enable into the encoder enable hook as a followup. Signed-off-by:
-
Ville Syrjälä authored
Since intel_ddi_enable_pipe_clock() was pushed down into the encoder hooks we can pass on the encoder instead of having to use intel_ddi_get_crtc_encoder(). Signed-off-by:
-
Peter Jones authored
This was sort of annoying me: random:~$ dmesg | tail -1 [523884.039227] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. random:~$ dmesg | grep -c "Reducing the compressed" 47 This patch makes it DRM_INFO_ONCE() just like the similar message farther down in that function is pr_info_once(). Cc: stable@vger.kernel.org Signed-off-by:
Peter Jones <pjones@redhat.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1745 Link: https://patchwork.freedesktop.org/patch/msgid/20180706190424.29194-1-pjones@redhat.com [vsyrjala: Rebase due to per-device logging] Signed-off-by:
-
Chris Wilson authored
Avoid flushing the submission queue (of others) under the client's timeline lock, but instead move it to the end so that we may catch more. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1066Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200420125356.26614-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since moving the obj->vma.list to a spin_lock, and the vm->bound_list to its vm->mutex, along with tracking shrinkable status under its own spinlock, we no long require the object to be locked by the caller. This is fortunate as it appears we can be called with the lock along an error path in flipping: <4> [139.942851] WARN_ON(debug_locks && !lock_is_held(&(&((obj)->base.resv)->lock.base)->dep_map)) <4> [139.943242] WARNING: CPU: 0 PID: 1203 at drivers/gpu/drm/i915/gem/i915_gem_domain.c:405 i915_gem_object_unpin_from_display_plane+0x70/0x130 [i915] <4> [139.943263] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core r8169 lpc_ich snd_pcm realtek prime_numbers [last unloaded: i915] <4> [139.943347] CPU: 0 PID: 1203 Comm: kms_flip Tainted: G U 5.6.0-gd0fda5c2cf3f1-drmtip_474+ #1 <4> [139.943363] Hardware name: /D510MO, BIOS MOPNV10J.86A.0311.2010.0802.2346 08/02/2010 <4> [139.943589] RIP: 0010:i915_gem_object_unpin_from_display_plane+0x70/0x130 [i915] <4> [139.943589] Code: 85 28 01 00 00 be ff ff ff ff 48 8d 78 60 e8 d7 9b f0 e2 85 c0 75 b9 48 c7 c6 50 b9 38 c0 48 c7 c7 e9 48 3c c0 e8 20 d4 e9 e2 <0f> 0b eb a2 48 c7 c1 08 bb 38 c0 ba 0a 01 00 00 48 c7 c6 88 a3 35 <4> [139.943589] RSP: 0018:ffffb774c0603b48 EFLAGS: 00010282 <4> [139.943589] RAX: 0000000000000000 RBX: ffff9a142fa36e80 RCX: 0000000000000006 <4> [139.943589] RDX: 000000000000160d RSI: ffff9a142c1a88f8 RDI: ffffffffa434a64d <4> [139.943589] RBP: ffff9a1410a513c0 R08: ffff9a142c1a88f8 R09: 0000000000000000 <4> [139.943589] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9a1436ee94b8 <4> [139.943589] R13: 0000000000000001 R14: 00000000ffffffff R15: ffff9a1410960000 <4> [139.943589] FS: 00007fc73a744e40(0000) GS:ffff9a143da00000(0000) knlGS:0000000000000000 <4> [139.943589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [139.943589] CR2: 00007fc73997e098 CR3: 000000002f5fe000 CR4: 00000000000006f0 <4> [139.943589] Call Trace: <4> [139.943589] intel_pin_and_fence_fb_obj+0x1c9/0x1f0 [i915] <4> [139.943589] intel_plane_pin_fb+0x3f/0xd0 [i915] <4> [139.943589] intel_prepare_plane_fb+0x13b/0x5c0 [i915] <4> [139.943589] drm_atomic_helper_prepare_planes+0x85/0x110 <4> [139.943589] intel_atomic_commit+0xda/0x390 [i915] <4> [139.943589] drm_atomic_helper_page_flip+0x9c/0xd0 <4> [139.943589] ? drm_event_reserve_init+0x46/0x60 <4> [139.943589] drm_mode_page_flip_ioctl+0x587/0x5d0 This completes the symmetry lost in commit 8b1c78e0 ("drm/i915: Avoid calling i915_gem_object_unbind holding object lock"). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1743 Fixes: 8b1c78e0 ("drm/i915: Avoid calling i915_gem_object_unbind holding object lock") Signed-off-by:
-
Lyude Paul authored
Looks like I accidentally made it so you couldn't force DPCD backlight support on, whoops. Fix that. Signed-off-by:
-
Jani Nikula authored
We have some module unload/reload tests hitting an issue with i915 unbinding the component interface before the audio driver has properly put the power. Log an error about it for ease of debugging. (Normally this leads to a wakeref debug splat on the power well.) Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Fix the warning caused by enabling the autosectionlabel extension in the kernel Sphinx build: Documentation/gpu/i915.rst:610: WARNING: duplicate label gpu/i915:layout, other instance in Documentation/gpu/i915.rst The autosectionlabel extension adds labels to each section title for cross-referencing, but forbids identical section titles in a document. With kernel-doc, this includes sections titles in the included kernel-doc comments. In the warning message, Sphinx is unable to reference the labels in their true locations in the kernel-doc comments in source. In this case, there's "Layout" sections in both gt/intel_workarounds.c and i915_reg.h. Rename the section in the latter to "File Layout". Fixes: 58ad30cf ("docs: fix reference to core-api/namespaces.rst") Reviewed-by:
-
- 18 Apr, 2020 3 commits
-
-
Michael J. Ruhl authored
DMA_MASK bit values are different for different generations. This will become more difficult to manage over time with the open coded usage of different versions of the device. Fix by: disallow setting of dma mask in AGP path (< GEN(5) for i915, add dma_mask_size to the device info configuration, updating open code call sequence to the latest interface, refactoring into a common function for setting the dma segment and mask info Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> cc: Brian Welty <brian.welty@intel.com> cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Colin Ian King authored
The variable test_result is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Anshuman Gupta authored
Gen11 onwards PG3 contains functions for pipe B, external displays, and VGA. Add missing ICL_DISP_PW_3 for ehl_power_wells. Cc: Animesh Manna <animesh.manna@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1737Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Acked-by:
-
- 17 Apr, 2020 1 commit
-
-
José Roberto de Souza authored
Right now dp.regs.dp_tp_ctl/status are only set during the encoder pre_enable() hook, what is causing all reads and writes to those registers to go to offset 0x0 before pre_enable() is executed. So if i915 takes the BIOS state and don't do a modeset any following link retraing will fail. In the case that i915 needs to do a modeset, the DDI disable sequence will write to a wrong register not disabling DP 'Transport Enable' in DP_TP_CTL, making a HDMI modeset in the same port/transcoder to not light up the monitor. So here for GENs older than 12, that have those registers fixed at port offset range it is loading at encoder/port init while for GEN12 it will keep setting it at encoder pre_enable() and during HW state readout. Fixes: 4444df6e ("drm/i915/tgl: move DP_TP_* to transcoder") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
