- 21 Apr, 2020 1 commit
-
-
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 <chris@chris-wilson.co.uk> Signed-off-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:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200420172739.11620-6-chris@chris-wilson.co.uk
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200417152734.464-2-ville.syrjala@linux.intel.comReviewed-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:
Jani Nikula <jani.nikula@intel.com>
-
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 17 commits
-
-
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:
-
José Roberto de Souza authored
This is a expected timeout of static TC ports not conneceted, so not throwing warnings that would taint CI. v3: - moved checks to tc_phy_aux_timeout_expected() v4: - moved and add comments to tc_phy_aux_timeout_expected() v5: - only checking tc_legacy_port for TC ports Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200414194956.164323-8-jose.souza@intel.com
-
José Roberto de Souza authored
As described in "drm/i915/tc/icl: Implement TC cold sequences" users of TC functions should held aux power well during access to avoid read garbage due HW in TC cold state. v3: - renamed is_tc_cold_blocked() to assert_tc_cold_blocked() - restored the removed 0xffffffff checks Reviewed-by:
You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by:
-
José Roberto de Souza authored
TC ports can enter in TCCOLD to save power and is required to request to PCODE to exit this state before use or read to TC registers. For TGL there is a new MBOX command to do that with a parameter to ask PCODE to exit and block TCCOLD entry or unblock TCCOLD entry. So adding a new power domain to reuse the refcount and only allow TC cold when all TC ports are not in use. v2: - fixed missing case in intel_display_power_domain_str() - moved tgl_tc_cold_request to intel_display_power.c - renamed TGL_TC_COLD_OFF to TGL_TC_COLD_OFF_POWER_DOMAINS - added all TC and TBT aux power domains to TGL_TC_COLD_OFF_POWER_DOMAINS v3: - added one msec sleep when PCODE returns -EAGAIN - added timeout of 5msec to not loop forever if sandybridge_pcode_write_timeout() keeps returning -EAGAIN v4: - Made failure to block or unblock TC cold a error - removed 5msec timeout, instead giving PCODE 1msec by up 3 times to recover from the internal error v5: - only sleeping 1msec when ret is -EAGAIN BSpec: 49294 Cc: Imre Deak <imre.deak@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
-
José Roberto de Souza authored
As part of ICL TC cold exit sequences we need to request aux power well before lock the access to TC ports, so skiping the intel_tc_port_ref_held() check for TC legacy ports. Reviewed-by:
-
José Roberto de Souza authored
This is required for legacy/static TC ports as IOM is not aware of the connection and will not trigger the TC cold exit. Just request PCODE to exit TCCOLD is not enough as it could enter again before driver makes use of the port, to prevent it BSpec states that aux powerwell should be held. So here embedding the TC cold exit sequence into ICL aux enable, it will enable aux and then request TC cold to exit. The TC cold block(exit and aux hold) and unblock was added to some exported TC functions for the others and to access PHY registers, callers should enable and keep aux powerwell enabled during access. Also adding TC cold check and warnig in tc_port_load_fia_params() as at this point of the driver initialization we can't request power wells, if we get this warning we will need to figure out how to handle it. v2: - moved ICL TC cold exit function to intel_display_power - using dig_port->tc_legacy_port to only execute sequences for legacy ports, hopefully VBTs will have this right - fixed check to call _hsw_power_well_continue_enable() - calling _hsw_power_well_continue_enable() unconditionally in icl_tc_phy_aux_power_well_enable(), if needed we will surpress timeout warnings of TC legacy ports - only blocking TC cold around fia access v3: - added timeout of 5msec to not loop forever if sandybridge_pcode_write_timeout() keeps returning -EAGAIN returning -EAGAIN in in icl_tc_cold_exit() - removed leftover tc_cold_wakeref - added one msec sleep when PCODE returns -EAGAIN v4: - removed 5msec timeout, instead giving 1msec to whoever is using PCODE to finish it up to 3 times - added a comment about turn TC cold exit failure as a error in future BSpec: 21750 Closes: https://gitlab.freedesktop.org/drm/intel/issues/1296 Cc: Imre Deak <imre.deak@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
-
José Roberto de Souza authored
This is a preparation for ICL TC cold exit sequences. v2: - renamed new functions to hsw_power_well_enable_prepare()/complete() Signed-off-by:
-
José Roberto de Souza authored
This is a similar function to intel_aux_power_domain() but it do not care about TBT ports, this will be needed by ICL TC sequences. v2: - renamed to intel_legacy_aux_to_power_domain() Cc: Imre Deak <imre.deak@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
-
José Roberto de Souza authored
Moving the code to return the digital port of the aux channel also removing the intel_phy_is_tc() to make it generic. digital_port will be needed in icl_tc_phy_aux_power_well_enable() so adding it as a parameter to icl_tc_port_assert_ref_held(). While at at removing the duplicated call to icl_tc_phy_aux_ch() in icl_tc_port_assert_ref_held(). v2: - fixed build when DRM_I915_DEBUG_RUNTIME_PM is not set - moved to before hsw_wait_for_power_well_enable() as it will be needed by hsw_wait_for_power_well_enable() in a future patch v4: - fixed action of if (!dig_port), continue instead of return Cc: You-Sheng Yang <vicamo@gmail.com> Reviewed-by:
-
José Roberto de Souza authored
The intel_display_power_put_async() used in TC cold sequences made easy to hit the missing deinitialization of driver in case of load failure as seen in the stack trace bellow. intel_modeset_driver_remove_noirq() had to be removed from i915_driver_modeset_remove_noirq() as those are different initialialition steps with IRQ and GEM initialization in between then. [drm:__intel_engine_init_ctx_wa [i915]] Initialized 3 context workarounds on rcs'0 [drm:__i915_inject_probe_error [i915]] Injecting failure -19 at checkpoint 36 [__uc_init:294] [drm:i915_hdcp_component_unbind [i915]] I915 HDCP comp unbind [drm:edp_panel_vdd_off_sync [i915]] Turning [ENCODER:275:DDI A] VDD off [drm:edp_panel_vdd_off_sync [i915]] PP_STATUS: 0x00000000 PP_CONTROL: 0x00000060 [drm:intel_power_well_disable [i915]] disabling AUX A general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1142 Comm: kworker/u16:20 Tainted: G U 5.6.0-CI-Patchwork_17226+ #1 Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019 Workqueue: events_unbound intel_display_power_put_async_work [i915] RIP: 0010:__intel_display_power_put_domain+0xa5/0x180 [i915] Code: 48 85 c0 78 54 44 89 e1 41 bd 01 00 00 00 49 c7 c4 80 44 41 a0 49 d3 e5 eb 0d 48 83 eb 10 48 3b 9d 08 ad 00 00 78 32 48 8b 03 <4c> 85 68 10 74 ea 8b 53 08 85 d2 74 2d 83 ea 01 85 d2 89 53 08 75 RSP: 0018:ffffc9000061fdb0 EFLAGS: 00010206 RAX: 6b6b6b6b6b6b6b6b RBX: ffff8884948f5df0 RCX: 000000000000003d RDX: 0000000080000001 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888479be0000 R08: ffff88849a180920 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0414480 R13: 2000000000000000 R14: ffff888479beb320 R15: 2000000000000000 FS: 0000000000000000(0000) GS:ffff88849ff80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005634fa8ed670 CR3: 0000000005610004 CR4: 0000000000760ee0 PKRU: 55555554 Call Trace: release_async_put_domains+0x9b/0x110 [i915] intel_display_power_put_async_work+0x91/0xf0 [i915] process_one_work+0x260/0x600 ? worker_thread+0xc9/0x380 worker_thread+0x37/0x380 ? process_one_work+0x600/0x600 kthread+0x119/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x24/0x50 Modules linked in: i915(+) vgem snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul cdc_ether usbnet mii snd_intel_dspcfg ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core e1000e ptp mei_me snd_pcm pps_core mei intel_lpss_pci prime_numbers [last unloaded: i915] ---[ end trace b402d1b4060f8b97 ]--- BUG: sleeping function called from invalid context at kernel/sched/completion.c:99 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1142, name: kworker/u16:20 INFO: lockdep is turned off. Preemption disabled at: [<0000000000000000>] 0x0 CPU: 3 PID: 1142 Comm: kworker/u16:20 Tainted: G UD 5.6.0-CI-Patchwork_17226+ #1 Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019 Workqueue: events_unbound intel_display_power_put_async_work [i915] Call Trace: dump_stack+0x71/0x9b ___might_sleep+0x178/0x260 wait_for_completion+0x37/0x1a0 virt_efi_query_variable_info+0x161/0x1b0 efi_query_variable_store+0xb3/0x1a0 ? efivar_entry_set_safe+0x19c/0x220 efivar_entry_set_safe+0x19c/0x220 ? efi_pstore_write+0x10b/0x150 ? efi_pstore_write+0xa0/0x150 efi_pstore_write+0x10b/0x150 pstore_dump+0x123/0x340 kmsg_dump+0x87/0x1b0 oops_end+0x3e/0x90 do_general_protection+0x1c3/0x2f0 general_protection+0x2d/0x40 RIP: 0010:__intel_display_power_put_domain+0xa5/0x180 [i915] Code: 48 85 c0 78 54 44 89 e1 41 bd 01 00 00 00 49 c7 c4 80 44 41 a0 49 d3 e5 eb 0d 48 83 eb 10 48 3b 9d 08 ad 00 00 78 32 48 8b 03 <4c> 85 68 10 74 ea 8b 53 08 85 d2 74 2d 83 ea 01 85 d2 89 53 08 75 RSP: 0018:ffffc9000061fdb0 EFLAGS: 00010206 RAX: 6b6b6b6b6b6b6b6b RBX: ffff8884948f5df0 RCX: 000000000000003d RDX: 0000000080000001 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888479be0000 R08: ffff88849a180920 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0414480 R13: 2000000000000000 R14: ffff888479beb320 R15: 2000000000000000 release_async_put_domains+0x9b/0x110 [i915] intel_display_power_put_async_work+0x91/0xf0 [i915] process_one_work+0x260/0x600 ? worker_thread+0xc9/0x380 worker_thread+0x37/0x380 ? process_one_work+0x600/0x600 kthread+0x119/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x24/0x50 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1142 at kernel/rcu/tree_plugin.h:293 rcu_note_context_switch+0x87/0x650 Modules linked in: i915(+) vgem snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul cdc_ether usbnet mii snd_intel_dspcfg ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core e1000e ptp mei_me snd_pcm pps_core mei intel_lpss_pci prime_numbers [last unloaded: i915] v2: - fixed handling in case of failure in drm_vblank_init() - moved i915_gem_driver_remove() call to before i915_driver_modeset_remove_noirq() this match initialization order too v3: - reverting call swap between i915_reset_error_state() and i915_gem_driver_remove() call order - improved label naming in i915_driver_modeset_probe_noirq() Closes: https://gitlab.freedesktop.org/drm/intel/issues/1647 Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Radhakrishna Sripada authored
Some workarounds are not sticking across suspend resume cycles. The forcewake ranges table has been updated and would reflect the hardware appropriately. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1222 v2: Simplify the table and use 0 for some unused ranges(Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
Chris Wilson authored
A basic premise of RPS is that at lower frequencies, not only do we run slower, but we save power compared to higher frequencies. For example, when idle, we set the minimum frequency just in case there is some residual current. Since the power curve should be a physical relationship, if we find no power saving it's likely that we've broken our frequency handling, so test! Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200417152018.13079-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Move the handy utility to measure the GPU energy consumption using RAPL msr into a common lib so that it can be reused easily. Signed-off-by:
-
Stanislav Lisovskiy authored
Lets have a unified way to handle SAGV changes, espoecially considering the upcoming Gen12 changes. Current "standard" way of doing this in commit_tail is pre/post plane updates, when everything which has to be forbidden and not supported in new config has to be restricted before update and relaxed after plane update. v2: - Removed unneeded returns(Ville) Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
Addressing one of the comments, recommending to extract platform specific code from intel_can_enable_sagv as a preparation, before we are going to add support for tgl+. v2: - Removed whitespace v3: - Removed premature debug and new cycle introduction(Ville) - Added missing no active pipes check(Ville) v4: - Fixed stupid mistake with plane_state caused by stupid macro change Signed-off-by: -
Stanislav Lisovskiy authored
Add correspondent helpers to be able to get old/new bandwidth global state object. v2: - Fixed typo in function call v3: - Changed new functions naming to use convention proposed by Jani Nikula, i.e intel_bw_* in intel_bw.c file. v4: - Change function naming back to intel_atomic* pattern, was decided to rename in a separate patch series. v5: - Fix function naming to match existing practices(Ville) v6: - Removed spurious whitespace v7: - Removed bw_state NULL checks(Ville) Reviewed-by: -
Chris Wilson authored
Since we are touching the device to read the registers, we are required to ensure the device is awake at the time. Currently, we believe ourselves to be inside the active request [thus an active engine wakeref], but since that may be retired in the background, we can spontaneously lose the wakeref and the ability to probe the HW. <4> [379.686703] RPM wakelock ref not held during HW access <4> [379.686805] WARNING: CPU: 7 PID: 4869 at ./drivers/gpu/drm/i915/intel_runtime_pm.h:115 gen12_fwtable_read32+0x233/0x300 [i915] <4> [379.686808] Modules linked in: i915(+) vgem snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ax88179_178a usbnet mii ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm e1000e mei_me ptp mei pps_core intel_lpss_pci prime_numbers [last unloaded: i915] <4> [379.686827] CPU: 7 PID: 4869 Comm: i915_selftest Tainted: G U 5.7.0-rc1-CI-CI_DRM_8313+ #1 <4> [379.686830] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A13.1912190237 12/19/2019 <4> [379.686883] RIP: 0010:gen12_fwtable_read32+0x233/0x300 [i915] <4> [379.686887] Code: d8 ea e0 0f 0b e9 19 fe ff ff 80 3d ad 12 2d 00 00 0f 85 17 fe ff ff 48 c7 c7 b0 32 3e a0 c6 05 99 12 2d 00 01 e8 2d d8 ea e0 <0f> 0b e9 fd fd ff ff 8b 05 c4 75 56 e2 85 c0 0f 85 84 00 00 00 48 <4> [379.686889] RSP: 0018:ffffc90000727970 EFLAGS: 00010286 <4> [379.686892] RAX: 0000000000000000 RBX: ffff88848cc20ee8 RCX: 0000000000000001 <4> [379.686894] RDX: 0000000080000001 RSI: ffff88843b1f0900 RDI: 00000000ffffffff <4> [379.686896] RBP: 0000000000000000 R08: ffff88843b1f0900 R09: 0000000000000000 <4> [379.686898] R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000a058 <4> [379.686900] R13: 0000000000000001 R14: ffff88848cc2bf30 R15: 00000000ffffffea <4> [379.686902] FS: 00007f7d63f5e300(0000) GS:ffff8884a0180000(0000) knlGS:0000000000000000 <4> [379.686904] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [379.686907] CR2: 000055e5c30f4988 CR3: 000000042e190002 CR4: 0000000000760ee0 <4> [379.686910] PKRU: 55555554 <4> [379.686911] Call Trace: <4> [379.686986] live_rps_interrupt+0xb14/0xc10 [i915] <4> [379.687051] ? intel_rps_unpark+0xb0/0xb0 [i915] <4> [379.687057] ? __trace_bprintk+0x57/0x80 <4> [379.687143] __i915_subtests+0xb8/0x210 [i915] <4> [379.687222] ? __i915_live_teardown+0x50/0x50 [i915] <4> [379.687291] ? __intel_gt_live_setup+0x30/0x30 [i915] <4> [379.687361] __run_selftests+0x112/0x170 [i915] <4> [379.687431] i915_live_selftests+0x2c/0x60 [i915] <4> [379.687491] i915_pci_probe+0x93/0x1b0 [i915] Signed-off-by:
-
