aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-13drm/i915/gt: Always reset the timeslice after a context switchChris Wilson1-2/+2
Currently, we reset the timer after a pre-eemption event. This has the side-effect that the timeslice runs into the second context after the first is completed after a normal promotion event, causing the second context to be swapped out early and switched for a third context. To be more fair, we want to reset the clock after promotion as well. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-13drm/i915: Fix too few arguments to function i915_capture_error_stateZhang Xiaoxu1-4/+2
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there is an error when compile the kernel: drivers/gpu/drm/i915/gt/intel_reset.c: In function intel_gt_handle_error: drivers/gpu/drm/i915/gt/intel_reset.c:1233:3: error: too few arguments to function i915_capture_error_state i915_capture_error_state(gt->i915); ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./drivers/gpu/drm/i915/i915_drv.h:97:0, from ./drivers/gpu/drm/i915/display/intel_display_types.h:46, from drivers/gpu/drm/i915/gt/intel_reset.c:10: ./drivers/gpu/drm/i915/i915_gpu_error.h:267:20: note: declared here static inline void i915_capture_error_state(struct drm_i915_private *dev_priv, Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capture") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhang Xiaoxu <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-13drm/i915: Fix multiple definition of 'i915_vma_capture_finish'Zhang Xiaoxu1-2/+3
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there are some errors like: drivers/gpu/drm/i915/i915_irq.o: In function `i915_vma_capture_finish': ./drivers/gpu/drm/i915/i915_gpu_error.h:312: multiple definition of `i915_vma_capture_finish' drivers/gpu/drm/i915/i915_drv.o: ./drivers/gpu/drm/i915/i915_gpu_error.h:312: first defined here So, add 'static inline' on the defineation of the 'i915_vma_capture_finish' Fixes: d713e3ab93fdc("drm/i915: Correct typo in i915_vma_compress_finish stub") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhang Xiaoxu <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-13drm/i915: Use the passed in encoderVille Syrjälä1-2/+2
Just use the passed in encoder instead of digging it out via the legacy drm_connector->encoder pointer (which we'll want to stop using). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ramalingam C <[email protected]>
2020-01-13drm/i915: Pass intel_encoder to enc_to_*()Ville Syrjälä22-212/+217
Lots of enc_to_foo(&encoder->base) around. Simplify by passing in the intel_encoder instead. @find@ identifier F =~ "^enc_to_.*"; identifier E; @@ F(struct drm_encoder *E) { ... } @@ identifier find.F; identifier find.E; @@ F( - struct drm_encoder *E + struct intel_encoder *encoder ) { <... - E + &encoder->base ...> } @@ identifier find.F; expression E; @@ - F(E) + F(to_intel_encoder(E)) @@ expression E; @@ - to_intel_encoder(&E->base) + E Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]>
2020-01-13drm/i915: Pass intel_connector to intel_attached_*()Ville Syrjälä9-54/+54
Life is usually easier when we pass around intel_ types instead of drm_ types. In this case it might not be, but I think being consistent is a good thing anyway. Also some of this might get cleaned up a bit more later as we keep propagating the intel_ types further. @find@ identifier F =~ "^intel_attached_.*"; identifier C; @@ F(struct drm_connector *C) { ... } @@ identifier find.F; identifier find.C; @@ F( - struct drm_connector *C + struct intel_connector *connector ) { <... - C + &connector->base ...> } @@ identifier find.F; expression C; @@ - F(C) + F(to_intel_connector(C)) @@ expression C; @@ - to_intel_connector(&C->base) + C Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Mika Kahola <[email protected]>
2020-01-13drm/i915: Bump up CDCLK to eliminate underruns on TGLStanislav Lisovskiy1-0/+12
There seems to be some undocumented bandwidth bottleneck/dependency which scales with CDCLK, causing FIFO underruns when CDCLK is too low, even when it's correct from BSpec point of view. Currently for TGL platforms we calculate min_cdclk initially based on pixel_rate divided by 2, accounting for also plane requirements, however in some cases the lowest possible CDCLK doesn't work and causing the underruns. We've found experimentally that raising cdclk to at least pixel_rate (rather than pixel_rate/2) eliminates these underruns, so let's use this as a temporary workaround until the hardware team can suggest a more precise remedy. Explicitly stating here that this seems to be currently rather a Hack, than final solution. v2: Use clamp operation instead of min(Matt Roper) v3: - Fixed commit message(Matt Roper) - Now using pixel_rate instead of max_cdclk(Jani Nikula) - Switched to max from clamp(Ville Syrjälä) Hopefully this hybrid satisfies everyone :) Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Stanislav Lisovskiy <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/issues/402 Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-13drm/i915/pmu: Do not use colons or dashes in PMU namesTvrtko Ursulin1-3/+8
We use PCI device path in the registered PMU name in order to distinguish between multiple GPUs. But since tools/perf reserves a special meaning to dash and colon characters we need to transliterate them to something else. We choose an underscore. v2: * Use strreplace. (Chris) * Dashes are not good either. (Chris) Signed-off-by: Tvrtko Ursulin <[email protected]> Reported-by: Dmitry Rogozhkin <[email protected]> Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Cc: Chris Wilson <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Andi Kleen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-11drm/i915: Correct typo in i915_vma_compress_finish stubChris Wilson1-2/+3
A copy and paste error in setting up the !CONFIG_DRM_I915_CAPTURE_ERROR stubs left a conflicting duplicate declaration. Reported-by: kbuild test robot <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Acked-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-11drm/i915/uc: Add sanitize to to intel_uc_opsMichal Wajdeczko2-9/+4
uC sanitization is only meaningful if we are running with uC present or enabled. Make this function part of the uc_ops. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-11drm/i915/uc: Add init/fini to to intel_uc_opsMichal Wajdeczko2-6/+10
uC preparation and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-11drm/i915/uc: Add init_fw/fini_fw to to intel_uc_opsMichal Wajdeczko2-6/+10
Firmware fetching and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-11drm/i915/uc: Add ops to intel_ucMichal Wajdeczko2-12/+54
Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. Begin with pair of init_hw/fini_hw functions that are responsible for uC hardware initialization and cleanup. v2: drop ops_none, use macro to generate ops helpers v3: reuse __uc_check_hw to avoid redundant comment v4: forward declare ops struct vs functions Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutexChris Wilson2-23/+19
We need to hold the runtime-pm wakeref to update the global PTEs (as they exist behind a PCI BAR). However, some systems invoke ACPI during runtime resume and so require allocations, which is verboten inside the vm->mutex. Ergo, we must not use intel_runtime_pm_get() inside the mutex, but lift the call outside. Closes: https://gitlab.freedesktop.org/drm/intel/issues/958 Signed-off-by: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)Vivek Kasireddy2-2/+100
Parsing the i2c element is mainly done to transfer the payload from the MIPI sequence block to the relevant slave device. In some cases, the commands that are part of the payload can be used to turn on the backlight. This patch is actually a refactored version of this old patch: https://lists.freedesktop.org/archives/intel-gfx/2014-December/056897.html In addition to the refactoring, the original patch is augmented by looking up the i2c bus from ACPI NS instead of relying on the bus number provided in the VBT. This patch was tested on Aava Mobile's Inari 10 tablet. It enabled turning on the backlight by transferring the payload to the device. v2: - Add DRM_DEV_ERROR for invalid adapter and failed transfer and also drop the DRM_DEBUG that existed originally. (Hans) - Add two gotos instead of one to clean things up properly. v3: - Identify the device on which this patch was tested in the commit message (Ville) Cc: Hans de Goede <[email protected]> Cc: Nabendu Maiti <[email protected]> Cc: Matt Roper <[email protected]> Cc: Bob Paauwe <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915: Drop request list from error stateChris Wilson2-70/+8
The list of requests from after the hang tells little about the hang itself, only how busy userspace was after the fact. As it pertains nothing to the HW state, drop it from the error state. Signed-off-by: Chris Wilson <[email protected]> Acked-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915: Drop the shadow ring state from the error captureChris Wilson2-9/+0
The shadow ring regs (ring->head, ring->tail) are meaningless in the post-mortem dump as they do not related to anything on HW. Remove them from the coredump. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915: Drop the shadow w/a batch bufferChris Wilson1-2/+0
While this is technically the batch as executed by the HW (in part at least), it is confusing, and only used for a minority of gen. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Acked-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915: Start chopping up the GPU error captureChris Wilson11-673/+877
In the near future, we will want to start a GPU error capture from a new context, from inside the softirq region of a forced preemption. To do so requires us to break up the monolithic error capture to provide new entry points with finer control; in particular focusing on one engine/gt, and being able to compose an error state from little pieces of HW capture. Signed-off-by: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Acked-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915/gt: Mark ring->vma as active while pinnedChris Wilson1-3/+28
As we use the active state to keep the vma alive while we are reading its contents during GPU error capture, we need to mark the ring->vma as active during execution if we want to include the rinbuffer in the error state. Reported-by: Lionel Landwerlin <[email protected]> Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Lionel Landwerlin <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915/gt: Mark context->state vma as active while pinnedChris Wilson1-0/+9
As we use the active state to keep the vma alive while we are reading its contents during GPU error capture, we need to mark the context->state vma as active during execution if we want to include it in the error state. Reported-by: Lionel Landwerlin <[email protected]> Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Lionel Landwerlin <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915/gt: Skip trying to unbind in restore_ggtt_mappingsChris Wilson1-5/+2
Currently we first to try to unbind the VMA (and lazily rebind on next use) as an optimisation during restore_ggtt_mappings. Ideally, the only objects in the GGTT upon resume are the pinned kernel objects which can't be unbound and need to be restored. As the unbind interferes with the plan to mark those objects as active for error capture, forgo the optimisation. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-10drm/i915/uncore: use new struct drm_device based macros.Wambui Karuga1-12/+13
Convert to the use of new struct drm_device based logging macros to replace the use of the printk based macros in i915/intel_uncore.c Signed-off-by: Wambui Karuga <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7142083e727ab400797c8a90a2196ee37a22c201.1578409433.git.wambui.karugax@gmail.com
2020-01-10drm/i915/sideband: convert to using new struct drm_device logging macrosWambui Karuga1-12/+17
Replace the use of printk based debugging macros with the struct drm_device based logging macros in i915/intel_sideband.c. Signed-off-by: Wambui Karuga <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ae253ecf3ca878fae7f1f246d75c2136fb6bd72c.1578409433.git.wambui.karugax@gmail.com
2020-01-10drm/i915/lmem: use new struct drm_device based logging macros.Wambui Karuga1-4/+6
Replace instances of printk based logging macros with the new struct drm_device logging macros in i915/intel_region_lmem.c. Signed-off-by: Wambui Karuga <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7f3df2575ab41a052b7beea86ecc5385edf6f6da.1578409433.git.wambui.karugax@gmail.com
2020-01-10drm/i915/pm: use new struct drm_device logging macros.Wambui Karuga1-157/+194
This converts various instances of the struct device and printk based logging macros with the new struct drm_device based logging macros in i915/intel_pm.c Signed-off-by: Wambui Karuga <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/8721848f7bcf8b0c3a33969d07e331bb372bd51a.1578409433.git.wambui.karugax@gmail.com
2020-01-10drm/i915/pch: convert to using the drm_dbg_kms() macro.Wambui Karuga1-22/+24
Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c. Signed-off-by: Wambui Karuga <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b79ee0f6efbf8358cbb4f2e163fa6b5bb04db794.1578409433.git.wambui.karugax@gmail.com
2020-01-09drm/i915/gtt: add missing include file asm/smp.hChen Zhou1-0/+1
Fix build error: drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings: drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of function wbinvd_on_all_cpus; did you mean wrmsr_on_cpus? [-Werror=implicit-function-declaration] wbinvd_on_all_cpus(); ^~~~~~~~~~~~~~~~~~ wrmsr_on_cpus Reported-by: Hulk Robot <[email protected]> Signed-off-by: Chen Zhou <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915: Pass cpu_transcoder to assert_pipe_disabled() alwaysVille Syrjälä2-3/+3
I missed a few assert_pipe_disabled() cases when changing it to take enum transcoder instead of enum pipe, making sparse unhappy. Convert the leftovers. Reported-by: kbuild test robot <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]>
2020-01-09drm/i915: Fix MST disable sequenceVille Syrjälä1-10/+12
When moving the pipe disable & co. function calls from haswell_crtc_disable() into the encoder .post_disable() hooks I neglected to account for the MST vs. DDI interactions properly. This now leads us to call these functions two times for the last MST stream (once from the MST code and a second time from the DDI code). The calls from the DDI code should only be done for SST and not MST. Add the proper check for that. This results in an MCE on ICL. My vague theory is that we turn off the transcoder clock from the MST code and then we proceed to touch something in the DDI code which still depends on that clock causing the hardware to become upset. Though I can't really explain why Stan's hack of omitting the pipe disable in the MST code would avoid the MCE since we should still be turning off the transcoder clock. But maybe there's something magic in the hw that keeps the clock on as long as the pipe is on. Or maybe the clock isn't the problem and we now touch something in the DDI disable code that really does need the pipe to be still enabled. v2: Rebase to latest drm-tip Cc: José Roberto de Souza <[email protected]> Cc: Manasi Navare <[email protected]> Reported-by: Stanislav Lisovskiy <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/issues/901 Fixes: 773b4b54351c ("drm/i915: Move stuff from haswell_crtc_disable() into encoder .post_disable()") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-01-09Merge drm/drm-next into drm-intel-next-queuedJani Nikula1334-15917/+33464
Sync with drm-next to get the new logging macros, among other things. Signed-off-by: Jani Nikula <[email protected]>
2020-01-09drm/i915: use true,false for bool variable in intel_crt.cMa Feng1-3/+3
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_crt.c:1066:1-28: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:928:2-29: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:443:2-29: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <[email protected]> Signed-off-by: Ma Feng <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915/dp: use true,false for bool variable in intel_dp.cMa Feng1-2/+2
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_dp.c:4950:1-33: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_dp.c:4906:1-33: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <[email protected]> Signed-off-by: Ma Feng <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915: use true,false for bool variable in i915_debugfs.cMa Feng1-2/+2
Fixes coccicheck warning: drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <[email protected]> Signed-off-by: Ma Feng <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915/gt: runtime-pm is no longer required for ce->ops->pin()Chris Wilson1-4/+1
Now that we have moved the runtime-pm management out of intel_context_acctive_acquire, and that itself out of ce->ops->pin(), no explicit runtime pm wakeref is required in intel_context_pin(). Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915/gt: Pull context activation into central intel_context_pin()Chris Wilson5-64/+40
While this is encroaching on midlayer territory, having already made the state allocation a previous step in pinning, we can now pull the common intel_context_active_acquire() into intel_context_pin() itself. This is a prelude to make the activation a separate step inside pinning, outside of the ce->pin_mutex Signed-off-by: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915/gt: Push context state allocation earlierChris Wilson2-8/+28
Allow for knowledgeable users to preallocate the context state, and to separate the allocation step from the pinning step during intel_context_pin() Signed-off-by: Chris Wilson <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915: Pin the context as we work on itChris Wilson4-20/+22
Since we now allow the intel_context_unpin() to run unserialised, we risk our operations under the intel_context_lock_pinned() being run as the context is unpinned (and thus invalidating our state). We can atomically acquire the pin, testing to see if it is pinned in the process, thus ensuring that the state remains consistent during the course of the whole operation. Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915: Revert "drm/i915/tgl: Wa_1607138340"Tvrtko Ursulin1-4/+0
This reverts commit 08fff7aeddc9dd72161b4c8fc27fbab12b4b9352. For some yet unexplained reason not having this improves stability of some media workloads. Promise is that the media hang will be root caused properly and in the meantime absence of this workaround is unlikely to cause problems. Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Sudeep Dutt <[email protected]> Cc: Francesco Balestrieri <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tony Ye <[email protected]> Acked-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915: Reduce warning for i915_vma_pin_iomap() without runtime-pmChris Wilson1-2/+2
Access through the GGTT (iomap) into the vma does require the device to be awake. However, we often take the i915_vma_pin_iomap() as an early preparatory step that is long before we use the iomap. Asserting that the device is awake at pin time does not protect us, and is merely a nuisance. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915: Early return for no-op i915_vma_pin_fence()Chris Wilson1-0/+3
If we have no fence and desire no fence on the vma, return before we try and take the vm->mutex. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm/i915/gt: Drop a defunct timeline assertionChris Wilson1-1/+0
intel_timeline_enter() has been decoupled from intel_timeline_pin() and both enter/exit & pin/unpin are allowed [read expected] to run concurrently with one another. The assertion that they had better not is stale. Closes: https://gitlab.freedesktop.org/drm/intel/issues/940 References: a6edbca74b30 ("drm/i915/gt: Close race between engine_park and intel_gt_retire_requests") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09Merge tag 'drm-misc-next-2020-01-07' of ↵Dave Airlie57-752/+2454
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.6: UAPI Changes: - Allow overriding number of bootup penguins in fbcon using fbcon=logo-count:n. Cross-subsystem Changes: - fbdev fixes for mmp, and make it work with CONFIG_COMPILE_TEST. - Use devm_platform_ioremap_resource in fbdev drivers. - Various small fbdev fixes. Core Changes: - Support scanline alignment for dumb buffers. - Add atomic_check() hook to bridge ops, to support bus format negotiation. - Add gem_create_object() to vram helpers. Driver Changes: - Rockchip: Add support for PX30. - Use generic fbdev code and dumb helpers in hisilicon/hibmc. - Add support for Leadtek LTK500HD1829 panel, and xinpeng XPP055C272. - Clock fixes for atmel-hlcdc. - Various smaller fixes to all drivers. Signed-off-by: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-09drm: of: Fix linking when CONFIG_OF is not setLaurent Pinchart1-2/+3
The new helper drm_of_lvds_get_dual_link_pixel_order() introduced in commit 6529007522de has a fallback stub when CONFIG_OF is not set, but the stub is declared in drm_of.h without a static inline. This causes multiple definitions of the function to be linked when the CONFIG_OF option isn't set. Fix it by making the stub static inline. Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Fabrizio Castro <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-08drm/i915/display: Fix warning about MST and DDI restrictionsJosé Roberto de Souza1-1/+4
Capturing the restrictions of the BSpec pages bellow: SKL and CNL do not support MST in DDI E, DDI E only support 2 lanes and it is mostly used to support a 4 lanes eDP panel together with DDI A. ICL's DDI E support MST just like other ports but DDI A is still eDP and MIPI only. TGL supports MST in any DDI, including DDI A but TGL has it's own ddi_pre_enable_dp function already without any warning. [ 215.579791] ------------[ cut here ]------------ [ 215.579794] WARN_ON(is_mst && (port == PORT_A || port == PORT_E)) [ 215.579875] WARNING: CPU: 0 PID: 268 at drivers/gpu/drm/i915/display/intel_ddi.c:3576 intel_ddi_pre_enable+0x124/0xea0 [i915] [ 215.579878] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core asix mei_hdcp cdc_ether x86_pkg_temp_thermal mei_me snd_pcm r8152 coretemp usbnet mei crct10dif_pclmul mii ptp ecdh_generic crc32_pclmul i2c_i801 ecc pps_core ghash_clmulni_intel thunderbolt [ 215.579905] CPU: 0 PID: 268 Comm: kworker/0:2 Tainted: G W 5.4.0-rc8-zeh+ #1307 [ 215.579907] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 [ 215.579912] Workqueue: events_long drm_dp_mst_link_probe_work [ 215.579975] RIP: 0010:intel_ddi_pre_enable+0x124/0xea0 [i915] [ 215.579978] Code: ff 8b 7c 24 10 89 44 24 30 85 ff 74 1f f7 44 24 18 fb ff ff ff 75 15 48 c7 c6 98 fa 48 a0 48 c7 c7 d3 df 4a a0 e8 cf d5 d0 e0 <0f> 0b 0f b6 4c 24 2c 41 8b b5 04 06 00 00 4c 89 e7 41 0f b6 95 0c [ 215.579980] RSP: 0018:ffffc90001a5f990 EFLAGS: 00010286 [ 215.579984] RAX: 0000000000000000 RBX: ffff88848356a000 RCX: 0000000000000000 [ 215.579986] RDX: 0000000000001df1 RSI: ffff88849340c998 RDI: ffffffff821489c5 [ 215.579989] RBP: ffff88848356a000 R08: 00000000c021a419 R09: 0000000000000000 [ 215.579991] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848356a118 [ 215.579994] R13: ffff88847f39c000 R14: ffff88847fe70000 R15: ffff88848356a000 [ 215.579996] FS: 0000000000000000(0000) GS:ffff88849f800000(0000) knlGS:0000000000000000 [ 215.579999] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 215.580001] CR2: 000055d3d5a26bc0 CR3: 0000000480ba6005 CR4: 0000000000760ef0 [ 215.580004] PKRU: 55555554 [ 215.580006] Call Trace: [ 215.580014] ? drm_dp_mst_topology_put_port+0x6f/0x130 [ 215.580072] intel_mst_pre_enable_dp+0x14b/0x170 [i915] [ 215.580129] intel_encoders_pre_enable+0x76/0x90 [i915] [ 215.580191] haswell_crtc_enable+0x84/0x880 [i915] [ 215.580266] intel_update_crtc+0x1e4/0x200 [i915] [ 215.580333] skl_commit_modeset_enables+0x287/0x420 [i915] [ 215.580405] intel_atomic_commit_tail+0x332/0x14e0 [i915] [ 215.580410] ? queue_work_on+0x41/0x70 [ 215.580489] intel_atomic_commit+0x31e/0x350 [i915] [ 215.580500] drm_client_modeset_commit_atomic+0x18b/0x220 [ 215.580523] drm_client_modeset_commit_force+0x4d/0x180 [ 215.580531] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 215.580538] drm_fb_helper_set_par+0x27/0x50 [ 215.580543] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0 [ 215.580549] drm_kms_helper_hotplug_event+0x21/0x30 [ 215.580553] process_one_work+0x25b/0x5b0 [ 215.580566] worker_thread+0x4b/0x3b0 [ 215.580578] kthread+0x100/0x140 [ 215.580581] ? process_one_work+0x5b0/0x5b0 [ 215.580585] ? kthread_park+0x80/0x80 [ 215.580591] ret_from_fork+0x24/0x50 [ 215.580603] irq event stamp: 1393930 [ 215.580606] hardirqs last enabled at (1393929): [<ffffffff8112a013>] vprintk_emit+0x143/0x330 [ 215.580609] hardirqs last disabled at (1393930): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20 [ 215.580613] softirqs last enabled at (1393434): [<ffffffff81c00389>] __do_softirq+0x389/0x47f [ 215.580618] softirqs last disabled at (1393423): [<ffffffff810b7199>] irq_exit+0xa9/0xc0 [ 215.580621] ---[ end trace afd44ea9caa6373e ]--- BSpec: 4217 BSpec: 14004 BSpec: 20584 BSpec: 50583 Cc: Matt Roper <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Lucas De Marchi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-08drm/i915/display/icl+: Do not program clockgatingJosé Roberto de Souza2-92/+0
Talked with HW team and this is a left over, driver should not program clockgating, mg or dekel firmware is reponsible for any clockgating programing. Also removing the register and bits definition related to clockgating. v2: Added WARN_ON v3: Only calling icl_phy_set_clock_gating() on intel_ddi_pre_enable_hdmi for GEN11 v4: ICL should also not program clockgating (thanks Matt for catching this) BSpec issue: 20885 BSpec: 49292 BSpec: 21735 Cc: Lucas De Marchi <[email protected]> Cc: Matt Roper <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-08drm/i915/display: Force the state compute phase once to enable PSRJosé Roberto de Souza4-0/+32
Recent improvements in the state tracking in i915 caused PSR to not be enabled when reusing firmware/BIOS modeset, this is due to all initial commits returning ealier in intel_atomic_check() as needs_modeset() is always false. To fix that here forcing the state compute phase in CRTC that is driving the eDP that supports PSR once. Enable or disable PSR do not require a fullmodeset, so user will still experience glitch free boot process plus the power savings that PSR brings. It was tried to set mode_changed in intel_initial_commit() but at this point the connectors are not registered causing a crash when computing encoder state. v2: - removed function return - change arguments to match intel_hdcp_atomic_check v3: - replaced drm includes in intel_psr.h by forward declaration(Jani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112253 Reported-by: <[email protected]> Cc: Gwan-gyeong Mun <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Gwan-gyeong Mun <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915/gt: Always force restore freshly pinned contextsChris Wilson1-1/+1
It is highly unlikely, but still conceivable, that we submit a context with the same GGTT address as last active on the HW. In this case, with a matching LRCA, the HW would not restore the new context image causing a potential violation of our context isolation. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Acked-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915/gtt: split up i915_gem_gttMatthew Auld23-4372/+4559
Attempt to split i915_gem_gtt.[ch] into more manageable chunks. Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915/gt: Take responsibility for engine->release as the last stepChris Wilson2-3/+6
In order to avoid a double cleanup on error, take ownership of engine->release past the point of no [error] return. Reported-by: Mika Kuoppala <[email protected]> Fixes: e26b6d434147 ("drm/i915/gt: Pull GT initialisation under intel_gt_init()") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Tested-by: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.