- 02 Jan, 2019 5 commits
-
-
Jani Nikula authored
The debugfs, error state and regular dmesg logging dump needs seem to be different. Remove the generic dump function only used for the welcome message. This may be added back later when better abstractions are identified, but at the moment this seems to be the simplest considering the device info rework in progress. No longer rely on device info being a substruct of dev_priv. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/70ff0c7c0ec3ef8747af3c78e272b5a82be3d55b.1546267488.git.jani.nikula@intel.com
-
Jani Nikula authored
Hide the way device info is stored, in preparation of making device info a pointer to the const rodata in i915_pci.c. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Jani Nikula authored
With the static/runtime device info split, this makes more sense. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Add a macro wrapper for display_mmio_offset access in register definitions. Prep work for reducing direct dev_priv->info usage. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
First move the low hanging fruit, the fields that are only initialized runtime. Use RUNTIME_INFO() exclusively to access the fields. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
- 31 Dec, 2018 13 commits
-
-
Chris Wilson authored
Now that we have eliminated the CPU-side irq_seqno_barrier by moving the delays on the GPU before emitting the MI_USER_INTERRUPT, we can remove the engine->irq_seqno_barrier infrastructure. Though intentionally slowing down the GPU is nasty, so is the code we can now remove! Signed-off-by:
-
Chris Wilson authored
The irq_seqno_barrier is a tradeoff between doing work on every request (on the GPU) and doing work after every interrupt (on the CPU). We presume we have many more requests than interrupts! However, for Ironlake, the workaround is a pretty hideous usleep() and so even though it was found we need to repeat the MI_STORE_DWORD_IMM 8 times, or about 1us of GPU time, doing so is preferrable than requiring a sleep of 125-250us on the CPU where we desire to respond immediately (ideally from within the interrupt handler)! The additional MI_STORE_DWORD_IMM also have the side-effect of flushing MI operations from userspace which are not caught by MI_FLUSH! Testcase: igt/gem_sync Testcase: igt/gem_exec_whisper Signed-off-by:
-
Chris Wilson authored
The irq_seqno_barrier is a tradeoff between doing work on every request (on the GPU) and doing work after every interrupt (on the CPU). We presume we have many more requests than interrupts! However, the current w/a for Ivybridge is an implicit delay that currently fails sporadically and consistently if we move the w/a into the irq handler itself. This makes the CPU barrier untenable for upcoming interrupt handler changes and so we need to replace it with a delay on the GPU before we send the MI_USER_INTERRUPT. As it turns out that delay is 32x MI_STORE_DWORD_IMM, or about 0.6us per request! Quite nasty, but the lesser of two evils looking to the future. Testcase: igt/gem_sync Signed-off-by:
-
Chris Wilson authored
The MI_FLUSH_DW does appear coherent with the following MI_USER_INTERRUPT, but only on Sandybridge. Ivybridge requires a heavier hammer, but on Sandybridge we can stop requiring the irq_seqno barrier. Testcase: igt/gem_sync Signed-off-by:
-
Chris Wilson authored
Having transitioned to using PIPECONTROL to combine the flush with the breadcrumb write using their post-sync functions, assume that this will resolve the serialisation with the subsequent MI_USER_INTERRUPT. That is when inspecting the breadcrumb after an interrupt we can rely on the write being posted (i.e. the HWSP will be coherent). Testing using gem_sync shows that the PIPECONTROL + CS stall does serialise the command streamer sufficient that the breadcrumb lands before the MI_USER_INTERRUPT. The same is not true for MI_FLUSH_DW. Signed-off-by:
-
Chris Wilson authored
Now that we perform the request flushing inline with emitting the breadcrumb, we can remove the now redundant manual flush. And we can also remove the infrastructure that remained only for its purpose. v2: emit_breadcrumb_sz is in dwords, but rq->reserved_space is in bytes Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_display.c:10708: warning: Function parameter or member 'cur' not described in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Function parameter or member 'new' not described in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Excess function parameter 'plane' description in 'intel_wm_need_update' drivers/gpu/drm/i915/intel_display.c:10708: warning: Excess function parameter 'state' description in 'intel_wm_need_update' References: cd1d3ee9 ("drm/i915: Use intel_ types more consistently for watermark code (v2)") Signed-off-by:
-
Jani Nikula authored
Macros with this much magic in them deserve some explanatory text. Reviewed-by:
-
Tvrtko Ursulin authored
It is only initialized to zero once so does not need an explicit initializer. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
i915.enable_hangcheck has been an outlier since its introduction in commit 3e0dc6b0 ("drm/i915: hangcheck disable parameter") with 0644 permissions, while all the rest are either 0400 or 0600. Follow suit with 0600. IGT never reads the value, so there should be no impact. Reviewed-by:
-
Jani Nikula authored
Reveals the build fail fixed in the last hunk. Also prep work. v2: name it i915 instead of dev_priv (Michal) Reviewed-by:
-
Jani Nikula authored
Abstract the one user in anticipation of more. Set the dangling pointers to NULL while at it. Reviewed-by:
-
Jani Nikula authored
Abstract the one user in anticipation of more. Reviewed-by:
-
- 28 Dec, 2018 7 commits
-
-
Chris Wilson authored
In preparation for removing the manual EMIT_FLUSH prior to emitting the breadcrumb implement the flush inline with writing the breadcrumb for ringbuffer emission. With a combined flush+breadcrumb, we can use a single operation to both flush and after the flush is complete (post-sync) write the breadcrumb. This gives us a strongly ordered operation that should be sufficient to serialise the write before we emit the interrupt; and therefore we may take the opportunity to remove the irq_seqno_barrier w/a for gen6+. Although using the PIPECONTROL to write the breadcrumb is slower than MI_STORE_DWORD_IMM, by combining the operations into one and removing the extra flush (next patch) it is faster For gen2-5, we simply combine the MI_FLUSH into the breadcrumb emission, though maybe we could find a solution here to the seqno-vs-interrupt issue on Ironlake by mixing up the flush? The answer is no, adding an MI_FLUSH before the interrupt is insufficient. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228153114.4948-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
In preparation for removing the manual EMIT_FLUSH prior to emitting the breadcrumb implement the flush inline with writing the breadcrumb for execlists. Using one command to both flush and write the breadcrumb is naturally a tiny bit faster than splitting it into two. Signed-off-by:
-
Chris Wilson authored
Having just gutted the implementation as there is no global seqno tracking, remove the vestigal write-only stub for debugfs/i915_next_seqno. Signed-off-by:
-
Chris Wilson authored
The writing is on the wall for the existence of a single execution queue along each engine, and as a consequence we will not be able to track dependencies along the HW queue itself, i.e. we will not be able to use HW semaphores on gen7 as they use a global set of registers (and unlike gen8+ we can not effectively target memory to keep per-context seqno and dependencies). On the positive side, when we implement request reordering for gen7 we also can not presume a simple execution queue and would also require removing the current semaphore generation code. So this bring us another step closer to request reordering for ringbuffer submission! The negative side is that using interrupts to drive inter-engine synchronisation is much slower (4us -> 15us to do a nop on each of the 3 engines on ivb). This is much better than it was at the time of introducing the HW semaphores and equally important userspace weaned itself off intermixing dependent BLT/RENDER operations (the prime culprit was glyph rendering in UXA). So while we regress the microbenchmarks, it should not impact the user. References: https://bugs.freedesktop.org/show_bug.cgi?id=108888Signed-off-by:
-
Chris Wilson authored
After we found a workaround for a hang on context load, Ben Widawsky found confirmation that it was for an issue with waking from rc6 and loading a context image. The workaround from on high suggests that we should I915_WRITE(RING_WAIT_FOR_RC6_EXIT(engine->mmio_base), _MASKED_FIELD(RING_RC6_SEL_WRITE_ADDR_MASK, RING_RC6_SEL_WRITE_ADDR_UPPER_LEFT)); in our rc6 setup for Haswell GT1, but on applying that we find instead that the machine encounters a GT forcewake error and locks up. As we are removing HW semaphore usage in the next patch, and the suggested workaround is no improvement, we need to decouple the PSMI workaround from HAS_SEMAPHORES to IS_HSW_GT1. References: 2c550183 ("drm/i915: Disable PSMI sleep messages on all rings around context switches") Signed-off-by:
-
Young Xiao authored
If for some unexpected reason the registers all read zero it's better to WARN and return instead of dividing by zero and completely freezing the machine. See commit 0e005888 ("drm/i915: avoid division by zero on cnl_calc_wrpll_link") for detail. Signed-off-by:
Young Xiao <YangX92@hotmail.com> Signed-off-by:
-
Brajeswar Ghosh authored
Remove video/mipi_display.h which is included more than once Signed-off-by:
Brajeswar Ghosh <brajeswar.linux@gmail.com> Signed-off-by:
-
- 27 Dec, 2018 2 commits
-
-
Chris Wilson authored
The information presented here is not relevant to current development. We can either use the context information, but more often we want to inspect the active gpu state. The ulterior motive is to eradicate dev->filelist. Signed-off-by:
-
Brajeswar Ghosh authored
Remove i915_scheduler.h which is included more than once Signed-off-by:
-
- 25 Dec, 2018 3 commits
-
-
Hans de Goede authored
Call intel_psr_enable() and intel_edp_drrs_enable() on pipe updates to make sure that we enable PSR / DRRS (when applicable) on fastsets. Note calling these functions when PSR / DRRS has already been enabled is a no-op, so it is safe to do this on every encoder->update_pipe callback. Changes in v2: -Merge the patches adding the intel_psr_enable() and intel_edp_drrs_enable() calls into a single patch Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181220132120.15318-3-hdegoede@redhat.com
-
Hans de Goede authored
Do not make it an error to call intel_edp_drrs_enable while drrs has already been enabled, instead exit silently in this case. This is a preparation patch for ensuring that DRRS is enabled on fastsets. Note that the removed WARN_ON could also be triggered from userspace through the i915_drrs_ctl debugfs entry which was added by commit 35954e88 ("drm/i915: Runtime disable for eDP DRRS") Reviewed-by:
-
Hans de Goede authored
When we are doing a fastset (needs_modeset=false, update_pipe=true) we may need to update some encoder-level things such as checking that PSR is enabled. This commit adds an update_pipe callback to intel_encoder and a new intel_encoders_update_pipe helper which calls this for all encoders connected to a crtc. The new intel_encoders_update_pipe helper is called from intel_update_crtc when doing a fastset. Changes in v2: -Name the new encoder callback update_pipe instead of just update Reviewed-by:
-
- 22 Dec, 2018 1 commit
-
-
Chris Wilson authored
If we fail to pin the ggtt vma slot for the ppgtt page tables, we need to unwind the locals before reporting the error. Or else on subsequent attempts to bind the page tables into the ggtt, we will already believe that the vma has been pinned and continue on blithely. If something else should happen to be at that location, choas ensues. Fixes: a2bbf714 ("drm/i915/gtt: Only keep gen6 page directories pinned while active") Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181222030623.21710-1-chris@chris-wilson.co.uk
-
- 21 Dec, 2018 4 commits
-
-
Rodrigo Vivi authored
Signed-off-by: -
Rodrigo Vivi authored
Signed-off-by: -
Paulo Zanoni authored
BSpec does not show these WAs as applicable to GLK, and for CNL it only shows them applicable for a super early pre-production stepping we shouldn't be caring about anymore. Remove these so we can avoid them on ICL too. v2: Change how we check for gen9 display platforms (Ville). Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Without this, we will get a dmesg-warn when enable_fbc is cleared on a fastset: WARN_ON(!crtc_state->enable_fbc) WARNING: CPU: 0 PID: 1090 at drivers/gpu/drm/i915/intel_fbc.c:1091 intel_fbc_enable+0x2ce/0x580 [i915] RIP: 0010:intel_fbc_enable+0x2ce/0x580 [i915] Call Trace: ? __mutex_unlock_slowpath+0x46/0x2b0 intel_update_crtc+0x6f/0x2b0 [i915] skl_update_crtcs+0x1d1/0x2b0 [i915] intel_atomic_commit_tail+0x1ea/0xdb0 [i915] intel_atomic_commit+0x244/0x330 [i915] drm_mode_atomic_ioctl+0x85d/0x950 ? drm_atomic_set_property+0x970/0x970 drm_ioctl_kernel+0x81/0xf0 drm_ioctl+0x2de/0x390 ? drm_atomic_set_property+0x970/0x970 ? __handle_mm_fault+0x81b/0xfc0 do_vfs_ioctl+0xa0/0x6e0 ? __do_page_fault+0x2a5/0x550 ksys_ioctl+0x35/0x60 __x64_sys_ioctl+0x11/0x20 do_syscall_64+0x55/0x190 entry_SYSCALL_64_after_hwframe+0x49/0xbe Changes since v1: - Move intel_fbc_disable to intel_update_crtc() (Hans) Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 20 Dec, 2018 1 commit
-
-
Manasi Navare authored
The DSC debugfs node causes a possible deadlock situation. This patch resets the try_again at the beginning of loop to fix this. Fixes: e845f099 ('drm/i915/dsc: Add Per connector debugfs node for DSC support/enable') Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109097 Cc: Lyude Paul <lyude@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
- 18 Dec, 2018 4 commits
-
-
Imre Deak authored
Add a fallback detection method for TypeC legacy ports in case the VBT port information used to detect normally such ports is incorrect. For the fallback method we use the TypeC legacy mode specific HPD interrupt flag which should only be raised for a legacy port. WARN if the VBT port info is incorrect. In a case where we'd detect the port in a contradicting way both as a legacy and also as a USB DP and/or TBT alternate port treat the port as legacy (by also emitting a WARN from icl_update_tc_port_type). v2: - Repurpose the detection as a fallback method instead of using it only for the DP legacy case. By now we should normally use VBT to detect DP legacy ports as well. Suggested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-5-imre.deak@intel.com
-
Imre Deak authored
Atm HPD disconnect events on TypeC ports will break things, since we'll switch the TypeC mode (between legacy and disconnected modes as well as among USB DP alternate, Thunderbolt alternate and disconnected modes) on the fly from the HPD disconnect interrupt work while the port may be still active. Even if the port happens to be not active during the disconnect we'd still have a problem during a subsequent modeset or AUX transfer that could happen regardless of the port's connected state. For instance the system resume display mode restore code and userspace could perform a modeset on the port or userspace could start an AUX transfer even if the port is in disconnected state. To fix this keep TypeC legacy ports in legacy mode whenever we're not suspended. This mode is a static configuration as opposed to the Thunderbolt and USB DP alternate modes between which we can switch dynamically. We determine if a TypeC port is legacy (wired to a legacy HDMI or a legacy DP connector) via the VBT DDI port specific USB-TypeC and Thunderbolt flags. If both these flags are cleared then the port is configured for legacy mode. On such legacy ports we'll run the TypeC PHY connect sequence explicitly during driver loading and system resume (vs. running the sequence during HPD processing). The connect will succeed even if the display is not connected to begin with (or disappears during the suspended state) since for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB DP alternate mode where it gets set only when a display is connected). Correspondingly run the TypeC PHY disconnect sequence during system suspend and driver unloading. For the unloading case I had to split up intel_dp_encoder_destroy() to be able to have the 1. flush any pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and kfree on the encoder object. For now run the PHY disconnect during suspend only for TypeC legacy ports. We will need to disconnect even in USB DP alternate mode in the future, but atm we don't have a way to reconnect the port in this mode during resume if the display disappears while being suspended. So for now punt on this case. Note that we do not disconnect the port during runtime suspend; in legacy mode there are no shared HW resources (PHY lanes) with other HW blocks (USB), so no need to release / reacquire these resources as with USB DP alternate mode. The only reason to disconnect legacy ports during system suspend is that the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be connected again during system resume. We'll also have to turn the check for this flag into a poll, after figuring out what's the proper timeout value for it. v2: - Remove the redundant special casing of legacy mode when doing a disconnect in icl_tc_port_connected(). It's guaranteed already that we won't disconnect legacy ports in that function. - Add a note about the new intel_ddi_encoder_destroy() hook. - Reword the commit message after switching to the VBT based detection. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
This is needed by the next patch to determine if a DDI TypeC port is physically wired to a legacy DP or legacy HDMI connector or if the port is wired to a USB-C/Thunderbolt connector. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
It's useful to see at which point a TypeC port gets disconnected, so add a debug print for it. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
