- 23 Mar, 2020 5 commits
-
-
Chris Wilson authored
Drop the pretense of kicking the tasklet (used only for the defunct guc submission backend, it should just take ownership of the submit!) and so remove the bh-kicking from around submission. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323092841.22240-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we store the handle lookup inside a radix tree, we do not need the gem_context->mutex except until we need to insert our lookup into the common radix tree. This takes a small bit of rearranging to ensure that the lut we insert into the tree is ready prior to actually inserting it (as soon as it is exposed via the radixtree, it is visible to any other submission). v2: For brownie points, remove the goto spaghetti. v3: Tighten up the closed-handle checks. Signed-off-by:
-
Chris Wilson authored
Abuse^W Take advantage that we know we are inside the GT wakeref and that prevents any client execbuf from reopening the i915_vma in order to claim all the vma to close without having to drop the spinlock to free each one individually. By keeping the spinlock, we do not have to restart if we run concurrently with i915_gem_free_objects -- which causes them both to restart continually and make very very slow progress. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1361 Fixes: 77853186 ("drm/i915: Claim vma while under closed_lock in i915_vma_parked()") Signed-off-by:
-
Chris Wilson authored
Since we take advantage of RCU for some i915_active objects, like the intel_timeline_cacheline, we need to delay the i915_active_fini until after the RCU grace period and we perform the kfree -- that is until after all RCU protected readers. <3> [108.204873] ODEBUG: assert_init not available (active state 0) object type: i915_active hint: __cacheline_active+0x0/0x80 [i915] <4> [108.207377] WARNING: CPU: 3 PID: 2342 at lib/debugobjects.c:488 debug_print_object+0x67/0x90 <4> [108.207400] Modules linked in: vgem snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec ax88179_178a snd_hwdep usbnet btusb snd_hda_core btrtl mii btbcm btintel snd_pcm bluetooth ecdh_generic ecc i915 i2c_hid pinctrl_sunrisepoint pinctrl_intel intel_lpss_pci prime_numbers <4> [108.207587] CPU: 3 PID: 2342 Comm: gem_exec_parall Tainted: G U 5.6.0-rc6-CI-Patchwork_17047+ #1 <4> [108.207609] Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019 <4> [108.207639] RIP: 0010:debug_print_object+0x67/0x90 <4> [108.207668] Code: 83 c2 01 8b 4b 14 4c 8b 45 00 89 15 87 d2 8a 02 8b 53 10 4c 89 e6 48 c7 c7 38 2b 32 82 48 8b 14 d5 80 2f 07 82 e8 49 d5 b7 ff <0f> 0b 5b 83 05 c3 f6 22 01 01 5d 41 5c c3 83 05 b8 f6 22 01 01 c3 <4> [108.207692] RSP: 0018:ffffc90000e7f890 EFLAGS: 00010282 <4> [108.207723] RAX: 0000000000000000 RBX: ffffc90000e7f8b0 RCX: 0000000000000001 <4> [108.207747] RDX: 0000000080000001 RSI: ffff88817ada8cb8 RDI: 00000000ffffffff <4> [108.207770] RBP: ffffffffa0341cc0 R08: ffff88816b5a8948 R09: 0000000000000000 <4> [108.207792] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82322d54 <4> [108.207814] R13: ffffffffa0341cc0 R14: ffffffff83df9568 R15: ffff88816064f400 <4> [108.207839] FS: 00007f437d753700(0000) GS:ffff88817ad80000(0000) knlGS:0000000000000000 <4> [108.207863] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [108.207887] CR2: 00007f2ad1fb5000 CR3: 00000001725d8004 CR4: 00000000003606e0 <4> [108.207907] Call Trace: <4> [108.207959] debug_object_assert_init+0x15c/0x180 <4> [108.208475] ? i915_active_acquire_if_busy+0x10/0x50 [i915] <4> [108.208513] ? rcu_read_lock_held+0x4d/0x60 <4> [108.208970] i915_active_acquire_if_busy+0x10/0x50 [i915] <4> [108.209380] intel_timeline_read_hwsp+0x81/0x540 [i915] <4> [108.210262] __emit_semaphore_wait+0x45/0x1b0 [i915] <4> [108.210726] ? i915_request_await_dma_fence+0x143/0x560 [i915] <4> [108.211156] i915_request_await_dma_fence+0x28a/0x560 [i915] <4> [108.211633] i915_request_await_object+0x24a/0x3f0 [i915] <4> [108.212102] eb_submit.isra.47+0x58f/0x920 [i915] <4> [108.212622] i915_gem_do_execbuffer+0x1706/0x2c70 [i915] <4> [108.213071] ? i915_gem_execbuffer2_ioctl+0xc0/0x470 [i915] Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200323092841.22240-1-chris@chris-wilson.co.uk
-
Anshuman Gupta authored
Few edp panels like Sharp is triggering short and long hpd pulse after panel is getting powered off. Currently driver is already ignoring long pulse for eDP panel but in order to process the short pulse, it turns on the VDD which requires panel power_cycle_delay + panel_power_on_delay these delay on Sharp panel introduced the responsiveness overhead of 800ms in the modeset sequence and as well is in suspend sequence. Ignoring any short pulse if panel is powered off. FIXME: It requires to wait for panel_power_off delay in order to check the panel power status due to pps_lock because panel triggers short pulse immediately after writing PP_OFF to PP_CTRL register and wait_panel_off waits for panel_power_off delay with pps_lock held. This still creates responsiveness overhead of panel_power_off delay. v2: - checking vdd along with panel power to ignore the hpd. [Jani,Ville] v3: - safer side check to ignore the long hpd when eDP have power, adding type of hpd to debug log. [Jani] Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318081837.23983-1-anshuman.gupta@intel.com
-
- 22 Mar, 2020 3 commits
-
-
Chris Wilson authored
Don't override our previous frequency we used after parking, and avoid continually spiking back to the efficient frequency for mostly idle workloads. Trust our ability to autotune across a workload switch. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we park/unpark faster than we can respond to RPS events, we never will process a downclock event after expiring a waitboost, and thus we will forever restart the GPU at max clocks even if the workload switches and doesn't justify full power. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500 Fixes: 3e7abf81 ("drm/i915: Extract GT render power state management") Signed-off-by:
-
Chris Wilson authored
A silly cut'n'paste copied the unlocked error path and used it inside the pin_mutex lock, we need to drop that lock before returning. Fixes: b412c63f ("drm/i915/gt: Report context-is-closed prior to pinning") Signed-off-by:
-
- 20 Mar, 2020 6 commits
-
-
Chris Wilson authored
Our assertion caught that we do try to pin a closed context if userspace is viciously racing context-closure with execbuf, so make it fail gracefully. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492Signed-off-by:
-
Ville Syrjälä authored
We only consider crtc_state->enable when initially calculating plane visibility. Later on we try to override the plane's state to invisible if the crtc is in DPMS off state (crtc_state->active==false). Unfortunately the code doing that only updates the plane_state.visible flag and the crtc_state.active_planes bimask, but forgets to update some of the other plane bitmasks stored in the crtc_state. Namely crtc_state.nv12_planes is left set up based on the original visibility check which makes icl_check_nv12_planes() pick a slave plane for the flagged plane in the bitmask. Later on we hit the watermark code which sees a plane with a slave assigned and it then makes the logical assumption that the master plane must itself be visible. Since the master's plane_state.visible flag was already cleared we get a WARN. Fix the problem by clearing all the plane bitmasks for DPMS off. This is more or less the wrong approach and instead we should calculate all the plane related state purely based crtc_state->enable (to guarantee that the subsequent DPMS on can't fail). However in the past we definitely had some roadblocks to making that happen. Not sure how many are left these days, but let's stick to the current approach since it's a much simpler fix to the immediate problem (the WARN). v2: Keep the visible=false, it's important (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318174515.31637-1-ville.syrjala@linux.intel.comReviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Gwan-gyeong Mun authored
It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by:Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
Gwan-gyeong Mun authored
It stores computed dp hdr metadata infoframe sdp to infoframes.drm of crtc state. It referenced intel_hdmi_compute_drm_infoframe(). While computing, we'll also fill out the infoframes.enable bitmask appropriately. v2: Wrap a long line. v4: Use struct drm_device logging macros v5: Fix typo [Uma] Signed-off-by:
-
Gwan-gyeong Mun authored
In order to support state readout for DP VSC SDP, we need to have a structure which holds DP VSC SDP payload data such as "union hdmi_infoframe drm" which is used for DRM infoframe. It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes. And it stores computed dp vsc sdp to infoframes.vsc of crtc state. While computing we'll also fill out the inforames.enable bitmask appropriately. The compute routine follows DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through DB18]. v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp v5: - Rebased - Add warning where a bpc is 6 and a pixel format is RGB. v7: Fix the wrong check of combination bpc 6 and RGB pixelformat Signed-off-by:
-
Gwan-gyeong Mun authored
It adds new enumeration definitions for VSC SDP Payload for Pixel Encoding/Colorimetry Format. And it adds a new drm data structure for DP VSC SDP. enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range". And enum dp_content_type corresponds "Content Type" All of them are based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through DB18]. v3: Add a new drm data structure for DP VSC SDP v5: Addressed review comments from Uma - Add kernel docs for added data structures - Rename enum dp_colorspace to dp_pixelformat - Polish commit message - Fix typos - Drop self-explanatory comments Signed-off-by:Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 19 Mar, 2020 11 commits
-
-
Chris Wilson authored
Use the restored ability to check if a context is closed to decide whether or not to immediately ban the context from further execution after a hang. Fixes: be90e344 ("drm/i915/gt: Cancel banned contexts after GT reset") Signed-off-by:
-
Chris Wilson authored
I need to keep the GEM context around a bit longer so adding an explicit flag for syncing execbuf with closed/abandonded contexts. v2: * Use already available context flags. (Chris) Signed-off-by:
-
Chris Wilson authored
%pS includes the offset, which is useful for return addresses but noise when we are pretty printing a known (and expected) function entry point. Signed-off-by:
-
Wambui Karuga authored
Replace the use of printk based drm logging macros with the struct drm_device based logging macros. Note that this converts DRM_DEBUG_DRIVER() to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Wambui Karuga authored
Replace the use of the printk based drm logging macros with the struct drm_device based logging macros in i915/gt/intel_rps.c. This also involves extracting the drm_i915_private device pointer from various intel types. This converts the instances of DRM_DEBUG_DRIVER to drm_dbg() while not converting DRM_DEBUG() instances due to the lack of an analogous drm_device based macro. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Replace the use of printk based drm logging macros to the struct drm_device based logging macros in i915/gt/intel_ring_submission.c. This was done using the following semantic patch that transforms based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were fixed manually. Note that this converts DRM_DEBUG_DRIVER to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by: -
Wambui Karuga authored
Replace the use of the printk based drm logging macros with the struct drm_device based logging macros. Signed-off-by:
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to use the struct drm_device logging macros. This also involves extracting the drm_i915_private device from intel types in some cases. Note that this converts DRM_DEBUG_DRIVER() to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros. Note that this converts DRM_DEBUG_DRIVER() to drm_dbg() but does not convert DRM_DEBUG() due to the lack of an analogous drm_device based macro. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to use the struct drm_device based logging macros in i915/gt/intel_ggtt.c. This change was done using the following coccinelle script that matches based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were fixed manually. Note that this converts DRM_DEBUG_DRIVER to drm_dbg() References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by: -
Swathi Dhanavanthri authored
Adding 4 new PCI IDs to TGL Bspec: 44455 Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200318221240.8180-1-swathi.dhanavanthri@intel.comReviewed-by:
-
- 18 Mar, 2020 6 commits
-
-
Mario Kleiner authored
This fixes a problem found on the MacBookPro 2017 Retina panel. The panel reports 10 bpc color depth in its EDID, and the firmware chooses link settings at boot which support enough bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc), but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps (multiplier value 0xa) as possible, in direct contradiction of what the firmware successfully set up. This restricts the panel to 8 bpc, not providing the full color depth of the panel. This patch adds a quirk specific to the MBP 2017 15" Retina panel to add the additiional 324000 kbps link rate during edp setup. Link to previous discussion of a different attempted fix with Ville and Jani: https://patchwork.kernel.org/patch/11325935/ v2: Follow Jani's proposal of defining quirk_rates[] instead of just appending 324000. This for better clarity. v3: Rebased onto current drm-tip, as of 16-March-2020. Adapt to new edid_quirks parameter of drm_dp_has_quirk(). Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by:
-
Wambui Karuga authored
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_hdcp.c. This also involves extracting the drm_i915_private device from the intel_connector type for use in the macros. v2 by Jani: - rebase Signed-off-by:
-
Wambui Karuga authored
Convert various instances of printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_fbdev.c. This also involves extracting the drm_i915_private device from various intel types. v2 by Jani: - fix the final one too Signed-off-by:
-
Wambui Karuga authored
This replaces the uses of the printk based drm logging macros with the struct drm_device based logging macros in i915/display/intel_fbc.c. This transformation was done using the following coccinelle semantic patch that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. v2 by Jani: - also convert pr_info_once to drm based logging Signed-off-by: -
Swati Sharma authored
For icl+, have hw read out to create hw blob of gamma lut values. icl+ platforms supports multi segmented gamma mode by default, add hw lut creation for this mode. This will be used to validate gamma programming using dsb (display state buffer) which is a tgl specific feature. v2: -readout code for multisegmented gamma has to come up with some intermediate entries that aren't preserved in hardware (Jani N) -linear interpolation (Ville) -moved common code to check gamma_enable to specific funcs, since icl doesn't support that v3: -use u16 instead of __u16 [Jani N] -used single lut [Jani N] -improved and more readable for loops [Jani N] -read values directly to actual locations and then fill gaps [Jani N] -moved cleaning to patch 1 [Jani N] -renamed icl_read_lut_multi_seg() to icl_read_lut_multi_segment to make it similar to icl_load_luts() -renamed icl_compute_interpolated_gamma_blob() to icl_compute_interpolated_gamma_lut_values() more sensible, I guess v4: -removed interpolated func for creating gamma lut values -removed readouts of fine and coarse segments, failure to read PAL_PREC_DATA correctly v5: -added gamma_enable check inside read_luts() v6: -renamed intel_color_lut_entry_equal() to intel_color_lut_entries_equal() [Ville] -changed if-else to switch [Ville] -removed intel_color_lut_entry_multi_equal() [Ville] v7: -checkpatch warnings v8: -rebased v9: -rebased, aligned with Ville's style of gamma cleanup Signed-off-by:Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Anshuman Gupta authored
As we have already enabled supported infrastructure for non-contiguous pipe fusing in driver, we don't require non-contiguous pipe_mask check anymore. It is an unlike condition, it make sense to remove this condition. changes since RFC: - using intel_pipe_mask_is_valid() function to check integrity of pipe_mask. [Ville] v2: - simplify condition in intel_pipe_mask_is_valid(). [Ville] v3: - removed non-contiguous pipe fusing check. [Lucas] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 17 Mar, 2020 8 commits
-
-
Umesh Nerlige Ramappa authored
On running several back to back perf capture sessions involving closing and opening the perf stream, invalid OA reports are seen in the beginning of the OA buffer in some sessions. Fix this by invalidating OA TLB when the perf stream is closed or disabled on gen12. Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 00a7f0d7 ("drm/i915/tgl: Add perf support on TGL") Signed-off-by:
-
Chris Wilson authored
In order to better respond to new heartbeat intervals given via sysfs, always reprogramme an active heartbeat upon change (i.e. use mod_delayed_work to reschedule rather than queue_delayed_work which ignores an already active work.) Signed-off-by:
-
Chris Wilson authored
Redirect references to i915_gem_fence_reg.c to gt/intel_ggtt_fencing.c Fixes: dec9cf9e ("drm/i915/gt: Pull restoration of GGTT fences underneath the GT") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200317141250.20903-1-chris@chris-wilson.co.uk
-
Lionel Landwerlin authored
On Gen11 powergating half the execution units is a functional requirement when using the VME samplers. Not fullfilling this requirement can lead to hangs. This unfortunately plays fairly poorly with the NOA requirements. NOA requires a stable power configuration to maintain its configuration. As a result using OA (and NOA feeding into it) so far has required us to use a power configuration that can work for all contexts. The only power configuration fullfilling this is powergating half the execution units. This makes performance analysis for 3D workloads somewhat pointless. Failing to find a solution that would work for everybody, this change introduces a new i915-perf stream open parameter that punts the decision off to userspace. If this parameter is omitted, the existing Gen11 behavior remains (half EU array powergating). This change takes the initiative to move all perf related sseu configuration into i915_perf.c v2: Make parameter priviliged if different from default v3: Fix context modifying its sseu config while i915-perf is enabled v4: Always consider global sseu a privileged operation (Tvrtko) Override req_sseu point in intel_sseu_make_rpcs() (Tvrtko) Remove unrelated changes (Tvrtko) v5: Some typos (Tvrtko) Process sseu param in read_properties_unlocked() (Tvrtko) v6: Actually commit the bits from v5... Fixup some checkpath warnings v7: Only compare engine uabi field (Chris) Signed-off-by: -
Lionel Landwerlin authored
The caller of i915_oa_init_reg_state() already sets this. Signed-off-by:
-
Lionel Landwerlin authored
A little bit of history : Back when i915-perf was introduced (4.13), there was no way to dynamically add new OA configurations to i915. Only the generated configs baked in at build time were allowed. It quickly became obvious that we would need to allow applications to upload their own configurations, for instance to be able to test new ones, and so by the next stable version (4.14) we added uAPIs to allow uploading new configurations. When adding that capability, we took the opportunity to remove most HW configurations except the TestOa one which is a configuration IGT would rely on to verify that the HW is outputting correct values. At the time it made sense to have that confiuration in at the same time a given HW platform added to the i915-perf driver. Now that IGT has become the reference point for HW configurations (see commit 53f8f541ca ("lib: Add i915_perf library"), previously this was located in the GPUTop repository), the need for having those configurations in i915-perf is gone. On the Mesa side, we haven't relied on this test configuration for a while. The MDAPI library always required 4.14 feature level and always loaded its configuration into i915. I'm sure nobody will miss this generated stuff in i915 :) v2: Fix selftests by creating an empty config v3: Fix unlocking on allocation error (Dan Carpenter) v4: Fixup checkpatch warnings v5: Fix incorrect unlock in error path (Umesh) Signed-off-by: -
Chris Wilson authored
Beware that the context may already be closed as we try to lookup an engine. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1389 Fixes: 130a95e9 ("drm/i915/gem: Consolidate ctx->engines[] release") Signed-off-by:
-
Chris Wilson authored
Apparently we do try and attach a fence to an invalid vma (during execbuf) so we cannot simply assert it never happens and report EINVAL instead. Fixes: dec9cf9e ("drm/i915/gt: Pull restoration of GGTT fences underneath the GT") Signed-off-by:
-
- 16 Mar, 2020 1 commit
-
-
Chris Wilson authored
Since the number of fence regs can vary dramactically between platforms, allocate the array on demand so we don't waste as much space. Signed-off-by:
-
