- 26 Feb, 2020 2 commits
-
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
- A backmerge of drm-next solving conflicts on i915/gt/intel_lrc.c - Clean up shadow batch after I915_EXEC_SECURE - Drop assertion that active->fence is unchanged Here goes drm-intel-next-2020-02-25: - A backmerge of drm-next solving conflicts on i915/gt/intel_lrc.c - Clean up shadow batch after I915_EXEC_SECURE - Drop assertion that active->fence is unchanged drm-intel-next-2020-02-24-1: - RC6 fixes - Chris - Add extra slice common debug register - Lionel - Align virtual engines uabi_class/instance with i915_drm.h - Tvrtko - Avoid potential division by zero in computing CS timestamp - Chris - Avoid using various globals - Michal Winiarski, Matt Auld - Break up long lists of GEM object reclaim - Chris - Check that the vma hasn't been closed before we insert it - Chris - Consolidate SDVO HDMI force_dvi handling - Ville - Conversion to new logging and warn macros and functions - Pankaj, Wambul, Chris - DC3CO fixes - Jose - Disable use of hwsp_cacheline for kernel_context - Chris - Display IRQ pre/post uninstall refactor - Jani - Display port sync refactor for robustness and fixes - Ville, Manasi - Do not attempt to reprogram IA/ring frequencies for dgfx - Chris - Drop alpha_support for good in favor of force_probe - Jani - DSI ACPI related fixes and refactors - Vivek, Jani, Rajat - Encoder refactor for flexibility to add more information, especiallly DSI related - Jani, Vandita - Engine workarounds refactor for robustness around resue - Daniele - FBC simplification and tracepoints - Various fixes for build - Jani, Kees Cook, Chris, Zhang Xiaoxu - Fix cmdparser - Chris - Fix DRM_I915_GEM_MMAP_OFFFSET - Chris - Fix i915_request flags - Chris - Fix inconsistency between pfit enable and scaler freeing - Stanislav - Fix inverted warn_on on display code - Chris - Fix modeset locks in sanitize_watermarks - Ville - Fix OA context id overlap with idle context id - Umesh - Fix pipe and vblank enable for MST - Jani - Fix VBT handling for timing parameters - Vandita - Fixes o kernel doc - Chris, Ville - Force full modeset whenever DSC is enabled at probe - Jani - Various GEM locking simplification and fixes - Jani , Chris, Jose - Including some changes in preparation for making GEM execbuf parallel - Chris - Gen11 pcode error codes - Matt Roper - Gen8+ interrupt handler refactor - Chris - Many fixes and improvements around GuC code - Daniele, Michal Wajdeczko - i915 parameters improvements sfor flexible input and better debugability - Chris, Jani - Ice Lake and Elkhart Lake Fixes and workarounds - Matt Roper, Jose, Vivek, Matt Atwood - Improvements on execlists, requests and other areas, fixing hangs and also improving hang detection, recover and debugability - Chris - Also introducing offline GT error capture - Chris - Introduce encoder->compute_config_late() to help MST - Ville - Make dbuf configuration const - Jani - Few misc clean ups - Ville, Chris - Never allow userptr into the new mapping types - Janusz - Poison rings after use and GTT scratch pages - Chris - Protect signaler walk with RCU - Chris - PSR fixes - Jose - Pull sseu context updates under gt - Chris - Read rawclk_freq earlier - Chris - Refactor around VBT handling to allow geting information through the encoder - Jani - Refactor l3cc/mocs availability - Chris - Refactor to use intel_connector over drm_connector - Ville - Remove i915_energy_uJ from debugfs - Tvrtko - Remove lite restore defines - Mika Kuoppala - Remove prefault_disable modparam - Chris - Many selftests fixes and improvements - Chris - Set intel_dp_set_m_n() for MST slaves - Jose - Simplify hot plug pin handling and other fixes around pin and polled modes - Ville - Skip CPU synchronization on dma-buf attachments - chris - Skip global serialization of clear_range for bxt vtd - Chris - Skip rmw for marked register - Chris - Some other GEM Fixes - Chris - Some small changes for satisfying static code analysis - Colin, Chris - Suppress warnings for unused debugging locals - Tiger Lake enabling, including re-enable -f RPS, workarounds and other display fixes and changes - Chris, Matt Roper, Mika Kuoppala, Anshuman, Jose, Radhakrishna, Rafael. - Track hw reported context runtime - Tvrtko - Update bug filling URL - Jani - Use async bind for PIN_USER into bsw/bxt ggtt - Chris - Use the kernel_context to measuer the breadcrumb size - Chris - Userptr fixes and robustness for big pages - Matt Auld - Various Display refactors and clean-ups, specially around logs and use of drm_i915_private - Jani, Ville - Various display refactors and fixes, especially around cdclk, modeset, and encoder - Chris, Jani - Various eDP/DP fixes around DPCD - Lyude - Various fixes and refactors for better Display watermark handling - Ville, Stanislav - Various other display refactors - Ville - Various refactor for better handling of display plane states - Ville - Wean off drm_pci_alloc/drm_pci_free - Chris - Correctly terminate connector iteration- Ville - Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt - Chris Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225185853.GA3282832@intel.com
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.7: UAPI Changes: Cross-subsystem Changes: Core Changes: - crtc: Drop get_crtc callback - dp: Add support for DP1.4 EDID corruption test - edid: Improve CEA detailed timings support - format-helper: Move to a GPL2/MIT dual license - mode: Drop drm_display_mode.private - vblank: Convert drm-driver vblank related code to CRTC equivalents and cleanup the core. - drm_global_mutex reworks Driver Changes: - hibmc: Add gamma_set support and improve DPMS support - pl111: Support Integrator IM-PD1 - sun4i: LVDS support for the A20, improvements to panel handling in DSI - virtio: job batching improvements, mem handling code rework - panel: Support for Rocktech RK101II01D-CT - bridge: Support for ADV7535, tc358768, improvements to ti-sn65dsi86 Signed-off-by:
-
- 25 Feb, 2020 6 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Rodrigo Vivi authored
Some DSI and VBT pending patches from Hans will apply cleanly and with less ugly conflicts if they are rebuilt on top of other patches that recently landed on drm-next. Reference: https://patchwork.freedesktop.org/series/70952/ Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com
-
Chris Wilson authored
We cannot assert the fence is not yet changed as the next thread may change it prior to acquiring our lock. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225082233.274530-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Tidy up after a call to eb_parse() if a later bind fails. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1312Signed-off-by:
-
Rodrigo Vivi authored
Signed-off-by: -
Rodrigo Vivi authored
Signed-off-by:
-
- 24 Feb, 2020 5 commits
-
-
Chris Wilson authored
Full-ppgtt on gen7 is proving to be highly unstable and not robust. Closes: https://gitlab.freedesktop.org/drm/intel/issues/694 Fixes: 3cd6e886 ("drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw") Signed-off-by:
-
José Roberto de Souza authored
Commit 60c6a14b ("drm/i915/display: Force the state compute phase once to enable PSR") was forcing the state compute too earlier causing errors because not everything was initialized, so here moving to the end of i915_driver_modeset_probe() when the display is all initialized. Also fixing the place where it disarm the force probe as during the atomic check phase errors could happen like the ones due locking and it would cause PSR to never be enabled if that happens. Leaving the disarm to the atomic commit phase, intel_psr_enable() or intel_psr_update() will be called even if the current state do not allow PSR to be enabled. v2: Check if intel_dp is null in intel_psr_force_mode_changed_set() v3: Check intel_dp before get dev_priv v4: - renamed intel_psr_force_mode_changed_set() to intel_psr_set_force_mode_changed() - removed the set parameter from intel_psr_set_force_mode_changed() - not calling intel_psr_set_force_mode_changed() from intel_psr_enable/update(), directly setting it after the same checks that intel_psr_set_force_mode_changed() does - moved intel_psr_set_force_mode_changed() arm call to i915_driver_modeset_probe() as it is a better for a PSR call, all the functions calls happening between the old and the new function call will cause issue Fixes: 60c6a14b ("drm/i915/display: Force the state compute phase once to enable PSR") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151Tested-by:
Ross Zwisler <zwisler@google.com> Reported-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221212635.11614-1-jose.souza@intel.com
-
Ville Syrjälä authored
One should use drm_connector_list_iter_end() rather than drm_connector_list_iter_begin() to terminate the connector iteration. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1278 Fixes: e24bcd34 ("drm/i915/dp: Add all tiled and port sync conns to modeset") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221154310.14858-1-ville.syrjala@linux.intel.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Jani Nikula authored
$(CC) with $(CFLAGS_GCOV) assumes the output filename with .gcno suffix appended is writable. This is not the case when the output filename is /dev/null: HDRTEST drivers/gpu/drm/i915/display/intel_frontbuffer.h /dev/null:1:0: error: cannot open /dev/null.gcno HDRTEST drivers/gpu/drm/i915/display/intel_ddi.h /dev/null:1:0: error: cannot open /dev/null.gcno make[5]: *** [../drivers/gpu/drm/i915/Makefile:307: drivers/gpu/drm/i915/display/intel_ddi.hdrtest] Error 1 make[5]: *** Waiting for unfinished jobs.... make[5]: *** [../drivers/gpu/drm/i915/Makefile:307: drivers/gpu/drm/i915/display/intel_frontbuffer.hdrtest] Error 1 Filter out $(CFLAGS_GVOC) from the header test $(c_flags) as they don't make sense here anyway. References: http://lore.kernel.org/r/d8112767-4089-4c58-d7d3-2ce03139858a@infradead.orgReported-by:
Randy Dunlap <rdunlap@infradead.org> Fixes: c6d4a099 ("drm/i915: reimplement header test feature") Cc: Masahiro Yamada <masahiroy@kernel.org> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221105414.14358-1-jani.nikula@intel.com
-
Chris Wilson authored
Restore the previous WARN_ON(cond) so that we don't complain about poor old Cherryview. Fixes: eb020ca3 ("drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available") Signed-off-by:
-
- 23 Feb, 2020 9 commits
-
-
Pankaj Bharadiya authored
drm specific 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 drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by:Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by:
-
Pankaj Bharadiya authored
drm specific 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 drm_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule4@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: -
Pankaj Bharadiya authored
drm specific 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 drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: -
Pankaj Bharadiya authored
drm specific 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 drm_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule4@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: -
Pankaj Bharadiya authored
drm specific 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 drm_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule4@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: -
Pankaj Bharadiya authored
drm specific 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 drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: -
Kees Cook authored
Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. drivers/gpu/drm/i915/display/intel_display.c: In function ‘check_digital_port_conflicts’: drivers/gpu/drm/i915/display/intel_display.c:12963:17: warning: statement will never be executed [-Wswitch-unreachable] 12963 | unsigned int port_mask; | ^~~~~~~~~ drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_get_fifo_size’: drivers/gpu/drm/i915/intel_pm.c:474:7: warning: statement will never be executed [-Wswitch-unreachable] 474 | u32 dsparb, dsparb2, dsparb3; | ^~~~~~ drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_atomic_update_fifo’: drivers/gpu/drm/i915/intel_pm.c:1997:7: warning: statement will never be executed [-Wswitch-unreachable] 1997 | u32 dsparb, dsparb2, dsparb3; | ^~~~~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916Reviewed-by:Kees Cook <keescook@chromium.org> Signed-off-by:
-
Jani Nikula authored
Ensure const data goes to rodata. Fixes: ff2cd863 ("drm/i915: Correctly map DBUF slices to pipes") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jani Nikula authored
Pair the irq install and uninstall in the same layer. There are no functional changes in the happy day scenario. The cleanup paths are currently a mess though. Note that modeset probe pre-irq + post-irq install are matched by modeset driver remove pre-irq + post-irq uninstall, together, but not independently. They are not symmetric pairs. v2: don't add a new probe failure point here Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 22 Feb, 2020 3 commits
-
-
Colin Ian King authored
Variable dw is being initialized with a value that is never read, it is assigned a new value later on. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Chris Wilson authored
Upon unregistering the user interface, we mark the GPU as wedged to ensure we push no new work to the GPU, and to flush all current work from the GPU. Move this call to the GT backend. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221235135.2883006-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We mark the vma as active while binding it in order to protect outselves from being shrunk under mempressure. This only works if we are strict in not attempting to shrink active objects. <6> [472.618968] Workqueue: events_unbound fence_work [i915] <4> [472.618970] Call Trace: <4> [472.618974] ? __schedule+0x2e5/0x810 <4> [472.618978] schedule+0x37/0xe0 <4> [472.618982] schedule_preempt_disabled+0xf/0x20 <4> [472.618984] __mutex_lock+0x281/0x9c0 <4> [472.618987] ? mark_held_locks+0x49/0x70 <4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60 <4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915] <4> [472.619122] i915_vma_unbind+0xae/0x110 [i915] <4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915] <4> [472.619208] i915_gem_shrink+0x328/0x660 [i915] <4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915] <4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915] <4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80 <4> [472.619363] ? __alloc_pd+0xb/0x30 [i915] <4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30 <4> [472.619368] ? __module_address+0x23/0xe0 <4> [472.619371] ? is_module_address+0x26/0x40 <4> [472.619374] ? static_obj+0x34/0x50 <4> [472.619376] ? lockdep_init_map+0x4d/0x1e0 <4> [472.619407] setup_page_dma+0xd/0x90 [i915] <4> [472.619437] alloc_pd+0x29/0x50 [i915] <4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915] <4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915] <4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915] <4> [472.619577] __vma_bind+0x26/0x40 [i915] <4> [472.619611] fence_work+0x1c/0x90 [i915] <4> [472.619617] process_one_work+0x26a/0x620 Fixes: 2850748e ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221221818.2861432-1-chris@chris-wilson.co.uk
-
- 21 Feb, 2020 6 commits
-
-
Matt Roper authored
We need to explicitly set the TLB Request Timer initial value in the BW_BUDDY registers to 0x8 rather than relying on the hardware default. v2: Apply missing REG_FIELD_PREP to ensure 0x8 is placed in the correct bits during the rmw. (Jose) Bspec: 52890 Bspec: 50044 Fixes: 3fa01d64 ("drm/i915/tgl: Program BW_BUDDY registers during display init") Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Chris Wilson authored
As there is a delay before we pin a vma, there is an opportunity for another thread to have closed the vm and its vma (including us). Check as soon as we acquire the vm->mutex and know the vm/vma is stable. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1291Signed-off-by:
-
Chris Wilson authored
Call cond_resched() between each freed object in case we have a really, really long list, and we don't want to block normal processes. Signed-off-by:
-
Michał Winiarski authored
Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915, will cause us to try and double free the global state, hitting null ptr deref in free_event_attributes. Let's move it to i915_pmu. Fixes: 05488673 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Michał Winiarski authored
Attempting to bind / unbind module from devices where we have both integrated and discreete GPU handled by i915 can lead to leaks and warnings from cpuhp: Error: Removing state XXX which has instances left. Let's move the state to i915_pmu. Fixes: 05488673 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by:
-
Wambui Karuga authored
Manual conversion of instances of printk based drm logging macros to the struct drm_device based logging macros in i915/i915_perf.c. Also involves extraction of the struct drm_i915_private device from various intel types for use in the macros. Instances of the DRM_DEBUG printk macro were not converted due to the lack of an analogous struct drm_device based logging macro. v2: remove instances of DRM_DEBUG that were converted. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.htmlSigned-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
- 20 Feb, 2020 9 commits
-
-
Matt Roper authored
On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL during display initialization, but on gen12 we're now supposed to program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well. v2: - Program registers with rmw to preserve contents of unrelated bits. - Switch to the new display uncore helpers. Bspec: 49213 Bspec: 50096 Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com>
-
Matt Roper authored
It wasn't terribly clear from the bspec's wording, but after discussion with the hardware folks, it turns out that we need to preserve the pre-existing contents of the MBUS ABOX control register when initializing a few specific bits. Bspec: 49213 Bspec: 50096 Fixes: 4cb4585e ("drm/i915/icl: initialize MBus during display init") Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We have to write quite a few registers when programming the pipe scaler. Let's use intel_de_write_fw() for these to reduce the lockdep overhead a bit. All plane registers (including plane scaler) already do this. We already had a few accidental intel_de_write_fw() in there. Signed-off-by:
-
Ville Syrjälä authored
Make the PFIT_PIPE stuff less ugly via parametrization. Signed-off-by:
-
Ville Syrjälä authored
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT} bits in intel_connector->polled (the base setting), leading to some confusing looking code to reset drm_connector->polled (the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd capable connectors, and then we don't need so many special cases in the hotplug code. Signed-off-by: -
Ville Syrjälä authored
No point in looping over all connectors for each hpd pin. Just loop over each connector first and deal with each one's hpd pin. Then loop over all the hpd pins to mark them as enabled again. Signed-off-by:
-
Ville Syrjälä authored
We have a nice little helper to compute a single LUT entry for everything except the 8bpc legacy gamma mode. Let's complete the set. Signed-off-by:
Emil Velikov <emil.velikov@collabora.com>
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.7: UAPI Changes: - lima: Add support for heap buffers Cross-subsystem Changes: Core Changes: - Implement mode_config mode_valid for memory constrained drivers - Bus format negociation between bridges - Consolidate fake vblank events for drivers without vblank interrupts - drm/bufs: dma_alloc related cleanups - drm/dp_mst: Various fixes - drm/print: New drm_device based print helpers - Thomas is a drm-misc maintainer now! Driver Changes: - DPMS cleanups for atomic drivers - Removal of owner field in SPI tinydrm drivers - Removal of explicit dependency on DT for tinydrm drivers - Conversion to YAML schemas for DT bindings - tidss: New driver - virtio: various reworks and fixes - Our usual dozen or so new panels or bridges Signed-off-by:
-
Daniele Ceraolo Spurio authored
We are quite trigger happy in cleaning up the firmware blobs, as we do so from several error/fini paths in GuC/HuC/uC code. We do have the __uc_cleanup_firmwares cleanup function, which unwinds __uc_fetch_firmwares and is already called both from the error path of gem_init and from gem_driver_release, so let's stop cleaning up from all the other paths. The fact that we're not cleaning the firmware immediately means that we can't consider firmware availability as an indication of initialization success. A "LOADABLE" status has been added to indicate that the initialization was successful, to be used to selectively load HuC only if HuC init has completed (HuC init failure is not considered a fatal error). v2: s/ready_to_load/loadable (Michal), only run guc/huc_fini if the fw is in loadable state Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
