- 15 Oct, 2019 17 commits
-
-
Mika Kuoppala authored
Avoid possible hang in tsg,vfe units by keeping l3 clocks runnings. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
If the system is being slow and userspace is racing ahead of the GPU and finds itself waiting for the GPU to catch up, before the process sleeps give the tasklet a kick, bypassing ksoftirqd. If the system is overloaded, then ksoftirqd may be delayed incurring additional latency to our user. This should not be a frequent problem, but in the past we have observed several hundred millisecond delays before ksoftirqd services an interrupt, so burn a few cycles to lend a helping hand. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015132606.14349-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Use the new drm_rect_init() helper where appropriate. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190930134214.24702-4-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Use the newly introduced drm_rect_translate_to() instead of hand rolling it. Signed-off-by:
-
Ville Syrjälä authored
While not all platforms allow us to change the cdclk frequency we should still verify that the fixed cdclk frequency isn't too low. To that end let's cook up a .modeset_calc_cdclk() implementation that only does the min_cdclk vs. actual cdclk frequency check for such platforms. Also we mustn't forget about double wide pipe on gen2/3 when doing this. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
We need to insert stuff between the plane and crtc .atomic_check() drm_atomic_helper_check_planes() doesn't allow us to do that so stop using it and hand roll the loops instead. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Now that we have standard defines for the MSA MISC bits lets use them on HSW+ where we program these directly into the TRANS_MSA_MISC register. Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
-
Gwan-gyeong Mun authored
It attaches HDR metadata property to DP connector on GLK+. It enables HDR metadata infoframe sdp on GLK+ to be used to send HDR metadata to DP sink. v2: Minor style fix Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Gwan-gyeong Mun authored
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP header and data block setup for HDR Static Metadata. It enables writing of HDR metadata infoframe SDP to panel. Support for HDR video was introduced in DisplayPort 1.4. It implements the CTA-861-G standard for transport of static HDR metadata. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. Because each of GEN11 and prior GEN11 have different register size for HDR Metadata Infoframe SDP packet, it adds and uses different register size. Setup Infoframe SDP header and data block in function intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per dp 1.4 spec and CTA-861-F spec. As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and Mastering Infoframe for HDR content, which is defined in CTA-861-F spec. According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3. +--------------------------------+-------------------------------+ | [ Packet Type Value ] | [ Packet Type ] | +--------------------------------+-------------------------------+ | 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME | +--------------------------------+-------------------------------+ | [Transmission Timing] | +----------------------------------------------------------------+ | As per CEA-861-F for INFOFRAME, including CEA-861.3 within | | which Dynamic Range and Mastering INFOFRAME are defined | +----------------------------------------------------------------+ v2: Add a missed blank line after function declaration. v3: Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] v9: Addressed review comments from Ville. - Add BUILD_BUG_ON to check a changing of struct dp_sdp size. - Change a passed size toward write_infoframe() for DP infoframe sdp packet for HDR static metadata. Signed-off-by: -
Gwan-gyeong Mun authored
According to Bspec, GEN11 and prior GEN11 have different register size for HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for GEN11. And it makes handle different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms. It addresses Uma's review comments. v9: Add WARN_ON() when buffer size if larger than register size. [Ville] Signed-off-by:
-
Gwan-gyeong Mun authored
It attaches the colorspace connector property to a DisplayPort connector. Based on colorspace change, modeset will be triggered to switch to a new colorspace. And in order to distinguish colorspace bwtween DP and HDMI connector, it adds a handling of drm_mode_create_dp_colorspace_property() to intel_attach_colorspace_property(). Based on colorspace property value create a VSC SDP packet with appropriate colorspace. This would help to enable wider color gamut like BT2020 on a sink device. v9: Addressed review comments from Ville - Add a handling of drm_mode_create_dp_colorspace_property() to intel_attach_colorspace_property(). This hunk moved from the previous commit. Signed-off-by: -
Gwan-gyeong Mun authored
When BT.2020 Colorimetry output is used for DP, we should program BT.2020 Colorimetry to MSA and VSC SDP. In order to handle colorspace of drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp(). And it also rename intel_ddi_set_pipe_settings() to intel_ddi_set_dp_msa(). As per DP 1.4a spec section 2.2.4 [MSA Data Transport] The MSA data that the DP Source device transports for reproducing the main video stream. Attribute data is sent once per frame during the main video stream’s vertical blanking period. In order to distinguish needed colorimetry for VSC SDP, it adds intel_dp_needs_vsc_sdp function. If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0, it uses MSA with VSC SDP. As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color Encoding Format and Content Color Gamut] while sending BT.2020 Colorimetry signals we should program MSA MISC1 fields which indicate VSC SDP for the Pixel Encoding/Colorimetry Format. v2: Remove useless parentheses v3: Addressed review comments from Ville - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state struct value. - Remove a pointless variable. v9: Addressed review comments from Ville - Remove a duplicated output color space from intel_crtc_state. - In order to handle colorspace of drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp(). Signed-off-by: -
Gwan-gyeong Mun authored
It refactors and renames a function which handled vsc sdp header and data block setup for supporting colorimetry format. Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block setup for pixel encoding / colorimetry format. In order to use colorspace information of a connector, it adds an argument of drm_connector_state type. Setup VSC header and data block in function intel_dp_setup_vsc_sdp for pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5, table 2-120: VSC SDP Payload for DB16 through DB18. Signed-off-by:
-
Chris Wilson authored
There is no significance to our delay before clearing the semaphore the engine is waiting on, so release it as soon as we acknowledge the CS update following our preemption request. This should allow the GPU to resume work earlier, if it was stuck on the semaphore at the end of a request. Signed-off-by:
-
Chris Wilson authored
We now do the page pin count upfront in vma_get_pages/vma_put_pages, so that we do the allocations before we enter the vm->mutex. Our vma page references we are tracked in vma->pages_count and the extra obj->pages_pin_count being performed later in i915_vma_insert and i915_vma_remove is redundant, and worse throws off the shrinker's logic on when it can free an object by unbinding it. Reported-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reported-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Chris Wilson authored
Before we attempt to set_pages on the vma, we claim a obj.pages_pin_count for it. If we subsequently fail to set the pages on the vma, we need to drop our pinning before returning the error. Reported-by:
-
Joonas Lahtinen authored
Backmerging to pull in HDR DP code: https://lists.freedesktop.org/archives/dri-devel/2019-September/236453.htmlSigned-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 14 Oct, 2019 12 commits
-
-
Lionel Landwerlin authored
We would like to make use of perf in Vulkan. The Vulkan API is much lower level than OpenGL, with applications directly exposed to the concept of command buffers (pretty much equivalent to our batch buffers). In Vulkan, queries are always limited in scope to a command buffer. In OpenGL, the lack of command buffer concept meant that queries' duration could span multiple command buffers. With that restriction gone in Vulkan, we would like to simplify measuring performance just by measuring the deltas between the counter snapshots written by 2 MI_RECORD_PERF_COUNT commands, rather than the more complex scheme we currently have in the GL driver, using 2 MI_RECORD_PERF_COUNT commands and doing some post processing on the stream of OA reports, coming from the global OA buffer, to remove any unrelated deltas in between the 2 MI_RECORD_PERF_COUNT. Disabling preemption only apply to a single context with which want to query performance counters for and is considered a privileged operation, by default protected by CAP_SYS_ADMIN. It is possible to enable it for a normal user by disabling the paranoid stream setting. v2: Store preemption setting in intel_context (Chris) v3: Use priorities to avoid preemption rather than the HW mechanism v4: Just modify the port priority reporting function v5: Add nopreempt flag on gem context and always flag requests appropriately, regarless of OA reconfiguration. Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/932Signed-off-by:Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Chris Wilson authored
Introduce a new perf_ioctl command to change the OA configuration of the active stream. This allows the OA stream to be reconfigured between batch buffers, giving greater flexibility in sampling. We inject a request into the OA context to reconfigure the stream asynchronously on the GPU in between and ordered with execbuffer calls. Original patch for dynamic reconfiguration by Lionel Landwerlin. Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/932Signed-off-by:
-
Lionel Landwerlin authored
Listing configurations at the moment is supported only through sysfs. This might cause issues for applications wanting to list configurations from a container where sysfs isn't available. This change adds a way to query the number of configurations and their content through the i915 query uAPI. v2: Fix sparse warnings (Lionel) Add support to query configuration using uuid (Lionel) v3: Fix some inconsistency in uapi header (Lionel) Fix unlocking when not locked issue (Lionel) Add debug messages (Lionel) v4: Fix missing unlock (Dan) v5: Drop lock when copying config content to userspace (Chris) v6: Drop lock when copying config list to userspace (Chris) Fix deadlock when calling i915_perf_get_oa_config() under perf.metrics_lock (Lionel) Add i915_oa_config_get() (Chris) Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/932Signed-off-by: -
Lionel Landwerlin authored
Reporting this version will help application figure out what level of the support the running kernel provides. v2: Add i915_perf_ioctl_version() (Chris) Signed-off-by:
-
Chris Wilson authored
We rely on only the tasklet being allowed to call into process_csb(), so assert that is locked when we do. As the tasklet uses a simple bitlock, there is no strong lockdep checking so we must make do with a plain assertion that the tasklet is running and assume that we are the tasklet! v2: Fixup intel_gt_sanitize() to prepare each engine for the reset so that the locks are marked as held during the reset v3: Check for existent function pointers for very early sanitisation. Signed-off-by:
-
Vivek Kasireddy authored
On platforms that have the MCC PCH, Port C's hotplug interrupt bits are mapped to TC1 bits. Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by:
-
Ville Syrjälä authored
The first come first served apporoach to handling the VBT child device AUX ch conflicts has backfired. We have machines in the wild where the VBT specifies both port A eDP and port E DP (in that order) with port E being the real one. So let's try to flip the preference around and let the last child device win once again. Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Tested-by:
Masami Ichikawa <masami256@gmail.com> Tested-by:
Torsten <freedesktop201910@liggy.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Fixes: 36a0f920 ("drm/i915/bios: make child device order the priority order") Signed-off-by:
-
Chris Wilson authored
Since commit e2144503 ("drm/i915: Prevent bonded requests from overtaking each other on preemption") we have restricted requests to run on their chosen engine across preemption events. We can take this restriction into account to know that we will want to resubmit those requests onto the same physical engine, and so can shortcircuit the virtual engine selection process and keep the request on the same engine during unwind. References: e2144503 ("drm/i915: Prevent bonded requests from overtaking each other on preemption") Signed-off-by:
Ramlingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191013203012.25208-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We want the general purpose registers to be clear in all new contexts so that we can be confident that no information is leaked from one to the next. Signed-off-by:
-
Chris Wilson authored
Check the logical ring context by asserting that the registers hold expected start during execution. (It's a bit chicken-and-egg for how could we manage to execute our request if the registers were not being updated. Still, it's nice to verify that the HW is working as expected.) Signed-off-by:
-
Chris Wilson authored
Just a parameter rename, drivers/gpu/drm/i915/display/intel_display.c:14425: warning: Function parameter or member '_new_plane_state' not described in 'intel_prepare_plane_fb' drivers/gpu/drm/i915/display/intel_display.c:14425: warning: Excess function parameter 'new_state' description in 'intel_prepare_plane_fb' drivers/gpu/drm/i915/display/intel_display.c:14534: warning: Function parameter or member '_old_plane_state' not described in 'intel_cleanup_plane_fb' drivers/gpu/drm/i915/display/intel_display.c:14534: warning: Excess function parameter 'old_state' description in 'intel_cleanup_plane_fb' Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_memory_region.o: in function `igt_mock_contiguous': drivers/gpu/drm/i915/selftests/intel_memory_region.c:166: undefined reference to `__umoddi3' v2: promote target to u64 for consistency across all builds Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 2f0b97ca ("drm/i915/region: support contiguous allocations") Signed-off-by:
-
- 13 Oct, 2019 1 commit
-
-
Chris Wilson authored
Use a local variable to track the allocation errors to avoid polluting the struct and keep the free simple. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 12 Oct, 2019 7 commits
-
-
Chris Wilson authored
When we are watching a particular context, we want the OA config to be applied inline with that context such that it takes effect before the next submission. Signed-off-by:
-
Lionel Landwerlin authored
We haven't run into issues with programming the global OA/NOA registers configuration from CPU so far, but HW engineers actually recommend doing this from the command streamer. On TGL in particular one of the clock domain in which some of that programming goes might not be powered when we poke things from the CPU. Since we have a command buffer prepared for the execbuffer side of things, we can reuse that approach here too. This also allows us to significantly reduce the amount of time we hold the main lock. v2: Drop the global lock as much as possible v3: Take global lock to pin global v4: Create i915 request in emit_oa_config() to avoid deadlocks (Lionel) v5: Move locking to the stream (Lionel) v6: Move active reconfiguration request into i915_perf_stream (Lionel) v7: Pin VMA outside request creation (Chris) Lock VMA before move to active (Chris) v8: Fix double free on stream->initial_oa_config_bo (Lionel) Don't allow interruption when waiting on active config request (Lionel) Signed-off-by: -
Lionel Landwerlin authored
NOA configuration take some amount of time to apply. That amount of time depends on the size of the GT. There is no documented time for this. For example, past experimentations with powergating configuration changes seem to indicate a 60~70us delay. We go with 500us as default for now which should be over the required amount of time (according to HW architects). v2: Don't forget to save/restore registers used for the wait (Chris) v3: Name used CS_GPR registers (Chris) Fix compile issue due to rebase (Lionel) v4: Fix save/restore helpers (Umesh) v5: Move noa_wait from drm_i915_private to i915_perf_stream (Lionel) v6: Add missing struct declarations in i915_perf.h Signed-off-by: -
Lionel Landwerlin authored
Here we introduce a mechanism by which the execbuf part of the i915 driver will be able to request that a batch buffer containing the programming for a particular OA config be created. We'll execute these OA configuration buffers right before executing a set of userspace commands so that a particular user batchbuffer be executed with a given OA configuration. This mechanism essentially allows the userspace driver to go through several OA configuration without having to open/close the i915/perf stream. v2: No need for locking on object OA config object creation (Chris) Flush cpu mapping of OA config (Chris) v3: Properly deal with the perf_metric lock (Chris/Lionel) v4: Fix oa config unref/put when not found (Lionel) v5: Allocate BOs for configurations on the stream instead of globally (Lionel) v6: Fix 64bit division (Chris) v7: Store allocated config BOs into the stream (Lionel) Signed-off-by: -
Chris Wilson authored
Sometimes we want to emit a terminator request, a request that flushes the pipeline and allows no request to come after it. This can be used for a "preempt-to-idle" to ensure that upon processing the context-switch to that request, all other active contexts have been flushed. Signed-off-by:
-
Chris Wilson authored
We set out-of-bound parameters inside the i915_requests.flags field, such as disabling preemption or marking the end-of-context. We should not coalesce consecutive requests if they have differing instructions as we only inspect the last active request in a context. Thus if we allow a later request to be merged into the same execution context, it will mask any of the earlier flags. References: 2a98f4e6 ("drm/i915: add infrastructure to hold off preemption on a request") Signed-off-by:
-
Chris Wilson authored
As we now have a specific engine to use OA on, exchange the top-level runtime-pm wakeref with the engine-pm. This still results in the same top-level runtime-pm, but with more nuances to keep the engine and its gt awake. Signed-off-by:
-
- 11 Oct, 2019 3 commits
-
-
Chris Wilson authored
Add the missing serialisation on the request for a write into a vma to wait until that vma is bound before being executed by the GPU. Signed-off-by:
-
Chris Wilson authored
Sometimes a test has to wait for RCU to complete a grace period and perform its callbacks, for example waiting for a close(fd) to actually perform the fput(filp) and so trigger all the callbacks such as closing GEM contexts. There is no trivial means of triggering an RCU barrier from userspace, so add one for our convenience in debugfs/i915_drop_caches Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011173823.20432-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Only the requests that have not completed do we want to change the status of to signal the -EIO when cancelling the inflight set of requests upon wedging. Reported-by:
-
