- 22 Jan, 2020 6 commits
-
-
Pankaj Bharadiya authored
Drm specific drm_WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_encoder struct pointer is available. The conversion was done automatically with below coccinelle semantic patch. @@ identifier func, T; @@ func(...) { ... struct intel_encoder *T = ...; <... ( -WARN( +drm_WARN(T->base.dev, ...) | -WARN_ON( +drm_WARN_ON(T->base.dev, ...) | -WARN_ONCE( +drm_WARN_ONCE(T->base.dev, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T->base.dev, ...) ) ...> } @@ identifier func, T; @@ func(struct intel_encoder *T,...) { <... ( -WARN( +drm_WARN(T->base.dev, ...) | -WARN_ON( +drm_WARN_ON(T->base.dev, ...) | -WARN_ONCE( +drm_WARN_ONCE(T->base.dev, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T->base.dev, ...) ) ...> } command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/display \ --linux-spacing --in-place 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/20200115034455.17658-5-pankaj.laxminarayan.bharadiya@intel.com
-
Jani Nikula authored
Merge tag 'topic/drm-warn-2020-01-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued struct drm_device based drm_WARN* macros Signed-off-by:
-
Pankaj Bharadiya authored
Add new struct drm_device based WARN* macros. These are modeled after the core kernel device based WARN* macros. These would be preferred over the regular WARN* macros, where possible. These macros include device information in the backtrace, so we know what device the warnings originate from. Knowing the device specific information in the backtrace would be helpful in development all around. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
Sean Paul <sean@poorly.run> Signed-off-by:
-
Chris Wilson authored
While we do flush writes to the vma before unbinding (to make sure they go through the right detiling register), we may also be concurrently poking at the GGTT_WRITE bit from set-domain, as we mark all GGTT vma associated with an object. We know this is for another vma, as we are currently unbinding this one -- so if this vma will be reused, it will be refaulted and have its dirty bit set before the next write. Closes: https://gitlab.freedesktop.org/drm/intel/issues/999Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121222447.419489-1-chris@chris-wilson.co.uk
-
Lyude Paul authored
Despite the fact that the VBT appears to have a field for specifying that a system is equipped with a panel that supports standard VESA backlight controls over the DP AUX channel, so far every system we've spotted DPCD backlight control support on doesn't actually set this field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI. While we don't know the exact reason for this VBT misuse, talking with some vendors indicated that there's a good number of laptop panels out there that supposedly support both PWM backlight controls and DPCD backlight controls as a workaround until Intel supports DPCD backlight controls across platforms universally. This being said, the X1 Extreme 2nd Gen that I have here (note that Lenovo is not the hardware vendor that informed us of this) PWM backlight controls are advertised, but only DPCD controls actually function. I'm going to make an educated guess here and say that on systems like this one, it's likely that PWM backlight controls might have been intended to work but were never really tested by QA. Since we really need backlights to work without any extra module parameters, let's take the risk here and rely on the standard DPCD caps to tell us whether AUX backlight controls are supported or not. We still check the VBT, just so we can print a debugging message on systems that advertise DPCD backlight support on the panel but not in the VBT. Changes since v3: * Print a debugging message if we enable DPCD backlight control on a device which doesn't report DPCD backlight controls in it's VBT, instead of warning on custom panel backlight interfaces. Signed-off-by:
Lyude Paul <lyude@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Perry Yuan <pyuan@redhat.com> Cc: AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
-
Jani Nikula authored
It's been a long enough transition period since the DRM_I915_FORCE_PROBE config and i915.force_probe module parameter were introduced in commit 7ef5ef5c ("drm/i915: add force_probe module parameter to replace alpha_support"). Remove alpha support. Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 21 Jan, 2020 16 commits
-
-
Chris Wilson authored
For a simulated preemption reset, we don't populate the request and so do not fill in the guilty context name. [ 79.991294] i915 0000:00:02.0: GPU HANG: ecode 9:1:e757fefe, in [0] Just don't mention the empty string in the logs! Fixes: 742379c0 ("drm/i915: Start chopping up the GPU error capture") Signed-off-by:
-
Ville Syrjälä authored
Eliminate the inconsistencies in the hdcp code local variables: - use dev_priv over dev - use to_i915() instead of dev->dev_private - initialize variables when declaring them - a bit of declaration suffling to appease ocd Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-10-ville.syrjala@linux.intel.comReviewed-by:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
Use the standard naming convention and rename conn_to_dig_port() to intel_attached_dig_port(). @@ @@ - conn_to_dig_port + intel_attached_dig_port (...) { ... } @@ expression C; @@ - conn_to_dig_port(C) + intel_attached_dig_port(C) Signed-off-by:Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Replace the hand rolled intel_attached_dp() with the real thing. @@ identifier F !~ "^intel_attached_dp$"; expression C; @@ F(...) { <... - enc_to_intel_dp(intel_attached_encoder(C)) + intel_attached_dp(C) ...> } v2: Regenerated Signed-off-by: -
Ville Syrjälä authored
We have uses for intel_attached_dp() outside of intel_dp.c. Move it to a header. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
It's easy to confuse the drm_connector->encoder (legacy state adjusted during modeset) and intel_connector->encoder (the statically (sans. MST) attached encoder of the connector). For the latter let's use intel_attached_encoder() consistently. @@ identifier F !~ "^intel_attached_encoder$"; struct intel_connector *C; expression E; @@ F(...) { <... ( C->encoder = E | - C->encoder + intel_attached_encoder(C) ) ...> } @@ identifier F !~ "^intel_attached_encoder$"; struct drm_connector *C; expression E; @@ F(...) { <... ( to_intel_connector(C)->encoder = E | - to_intel_connector(C)->encoder + intel_attached_encoder(to_intel_connector(C)) ) ...> } v2: Regenerated Signed-off-by: -
Jani Nikula authored
Provide slightly more debugging help. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Report port presence based on port presence in VBT alone, relaxing the requirements on supported encoders (DP, DVI, or HDMI). The goal is to make future changes easier, however there is a small risk of reporting more ports present than before in case of dubious VBT. Regarding the current callers of intel_bios_is_port_present(), the potential issue might be caused by DVO_PORT_CRT being identified as port E in dvo_port_to_port(). Hopefully no VBT has that on SKL+ which support DP/DVI/HDMI on port E; the current CRT init code on HSW/BDW does not care. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
Jani Nikula authored
Don't access i915->vbt.ddi_port_info[] directly. Reviewed-by:
-
- 20 Jan, 2020 10 commits
-
-
Chris Wilson authored
Currently we create a new mmap_offset for every call to mmap_offset_ioctl. This exposes ourselves to an abusive client that may simply create new mmap_offsets ad infinitum, which will exhaust physical memory and the virtual address space. In addition to the exhaustion, a very long linear list of mmap_offsets causes other clients using the object to incur long list walks -- these long lists can also be generated by simply having many clients generate their own mmap_offset. However, we can simply use the drm_vma_node itself to manage the file association (allow/revoke) dropping our need to keep an mmo per-file. Then if we keep a small rbtree of per-type mmap_offsets, we can lookup duplicate requests quickly. Fixes: cc662126 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET") Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120104924.4000706-3-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Move the force_dvi check to a single function that can be called from both mode validation and compute_config(). Note that currently we don't call it from mode validation, but that will change soon. Signed-off-by:
-
Ville Syrjälä authored
Move the force_dvi check to a single function that can be called from both mode validation and compute_config(). Signed-off-by:
-
Ville Syrjälä authored
The strings we want to print to the on stack buffers should be no more than 8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61 bytes. So let's shrink the buffers down to 64 bytes. Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in my arithmentic. Signed-off-by: -
Ville Syrjälä authored
Let's not pollute the function scope with variables when they're only needed inside some loops. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it so we get the mismatch printed in hex instead of decimal. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Tested-by:
-
Ville Syrjälä authored
Let's use the pipe rather than the silly 'i' iterator from for_each_oldnew_intel_crtc_in_state() for indexing the ddb entries array. Maybe one day we can assume c99 and hide the 'i' entirely from sight. Signed-off-by:
-
Ville Syrjälä authored
Currently we don't call intel_crtc_prepare_cleared_state() for crtcs that are going to be entirely disabled (uapi.enable==false). That means such crtcs will leave stale junk lying around in their states and we have to sprinkle hw.enable checks all over before we can look at the states. Let's change that a bit so that we aways do the state clearing, even for fully disabled crtcs. Note that we still keep some parts of the old state (see intel_crtc_prepare_cleared_state() for the details) so probably can't trust things 100% when hw.enable==false. But at least there's less chance now that we end up looking at stale junk. Signed-off-by:
-
Ville Syrjälä authored
The post-fastset "does anyone still need a full modeset?" for port sync looks busted. The outer loop bails out of a full modeset is still needed by the current crtc, and then we skip forcing a full modeset on the related crtcs. That's totally the opposite of what we want. The MST path has the logic mostly the other way around so it looks correct. To fix the port sync case let's follow the MST logic for both. So, if the current crtc already needs a modeset we do nothing. otherwise we check if any of the related crtcs needs a modeset, and if so we force a full modeset for the current crtc. And while at let's change the else if to a plain if to so we don't have needless coupling between the MST and port sync checks. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 05a8e451 ("drm/i915/display: Use external dependency loop for port sync") Signed-off-by:
-
Tvrtko Ursulin authored
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by:
-
- 18 Jan, 2020 1 commit
-
-
Chris Wilson authored
Just in the very unlikely case we have not stopped the GPU before we return the pages being used by the GPU to the system, force a reset. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200117180309.3249427-1-chris@chris-wilson.co.uk
-
- 17 Jan, 2020 7 commits
-
-
Matthew Auld authored
If we create a rather large userptr object(e.g 1ULL << 32) we might shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT, resulting in a totally bogus sg_table, which fortunately will eventually manifest as: gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size) kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463! v2: more unsigned long prefer I915_GTT_PAGE_SIZE Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Signed-off-by: -
Matthew Auld authored
Don't allow a mismatch between obj->base.size/vma->size and the actual number of pages for the backing store, which is limited to INT_MAX pages. v2: document what are missing before we can safely drop the limit check Signed-off-by:
-
Chris Wilson authored
Since commit 22b7a426 ("drm/i915/execlists: Preempt-to-busy"), we prune the engine->active.requests list prior to preemption, thus removing the trace of the currently executing request. If that request hangs rather than be preempted, we conclude that no active request was on the GPU. Fortunately, this only impacts our debugging, and not our means of hang detection or recovery. v2: Use from to check the current iterator before continuing, and report active as NULL if the current request is already completed. References: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
Wambui Karuga authored
Replace the use of printk based logging macros with the new struct drm_device based logging macro in i915/intel_memory_region.c. Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Wambui Karuga authored
This converts the use of printk based logging macros in i915/intel_gvt.c with the new struct drm_device based logging macros. Signed-off-by:
-
Wambui Karuga authored
This replaces the printk and struct device based logging macros with the new struct drm_device style based logging macros i915/intel_device_info.c. Signed-off-by:
-
Wambui Karuga authored
Replace the use of printk and struct device based logging macros with the new struct drm_device based logging macros in i915/intel_csr.c Signed-off-by:
-
