- 14 Mar, 2019 3 commits
-
-
Chris Wilson authored
Since both GPU reset and declaring the device wedged suspend ongoing driver activity around a hard reset, we can reuse the same code to reduce the likelihood of forgetting details surrounding reset from either path. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314084432.3740-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The impossible happens and a future fence expired while we were still initialising. The probable cause is that the test was preempted and we lost our scheduler cpu slice. Disable preemption during this test to rule out preemption as a source of timer disruption. References: https://bugs.freedesktop.org/show_bug.cgi?id=110039Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190313205944.5768-1-chris@chris-wilson.co.uk
-
Sujaritha Sundaresan authored
Adding the call to prepare for guc reset along with engine reset. intel_uc_reset_prepare() calls to disable guc communication and to sanitize. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
- 13 Mar, 2019 7 commits
-
-
José Roberto de Souza authored
When any other value than EDP_PSR_TP4_TIME_0US is set, TPS1 and TPS4 will be used to do the link training when exiting PSR1. Happily the eDP panels tested so far was able to sync with source even without HBR3/TPS4 support but let use the right training pattern. TPS4 support was added to PSR1 registers because HBR3/PSR specification was not closed when ICL was freezed so if HBR3 was supported by PSR, ICL would already be ready but it was not added to specification so lets always disable TPS4. v3: Missed ";" SPANK SPANK SPANK!!! BSpec: 17524 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190312195743.8829-3-jose.souza@intel.com
-
José Roberto de Souza authored
This will make hsw_activate_psr1() more easy to read and will make future modification to TPS registers more easy to review and read. v4: Rename new function to intel_psr1_get_tp_time() (Dhinakaran and Rodrigo) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
José Roberto de Souza authored
A new field with the training pattern(TP) wakeup time for PSR2 was added to VBT, so lets use it when available otherwise it will fallback to PSR1 wakeup time. v2: replacing enum to numerical usec time (Jani) BSpec: 20131 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
In order to make it easier to bring up new platforms without having to take care about all corner cases that was previously taken care for previous platforms we already use comparative INTEL_GEN statements. Let's start doing the same with PCH. The only caveats are: - less-than comparisons need to be avoided or done with attention and check > PCH_NONE as well. - It is not necessarily a chronological order, but a matter of south display compatibility/inheritance. v2: Rebased on top of Jani's clean-up which removed the need for less-than comparison Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308214300.25057-3-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
So we can later use PCH >= comparisons. The ultimate goal is to make it easier for us to introduce a new platform with south display engine on PCH just by reusing the previous one. Suggested-by:
-
Rodrigo Vivi authored
This exactly same approach was already used from gen9 to gen10 and from gen10 to gen11. Let's also use it for gen11+. Let's first assume that we inherit a similar platform and than we apply the differences on top. Different from the previous attempts this will be done this time with coccinelle. We obviously need to exclude some case that is really exclusive for gen11 like PCH, Firmware, and few others. Luckly this was easy to filter by selecting the files we are touching with coccinelle as exposed below: spatch -sp_file gen11\+.cocci --in-place i915_perf.c \ intel_bios.c intel_cdclk.c intel_ddi.c \ intel_device_info.c intel_display.c intel_dpll_mgr.c \ intel_dsi_vbt.c intel_hdmi.c intel_mocs.c intel_color.c @noticelake@ expression e; @@ -!IS_ICELAKE(e) +INTEL_GEN(e) < 11 @notgen11@ expression e; @@ -!IS_GEN(e, 11) +INTEL_GEN(e) < 11 @icelake@ expression e; @@ -IS_ICELAKE(e) +INTEL_GEN(e) >= 11 @gen11@ expression e; @@ -IS_GEN(e, 11) +INTEL_GEN(e) >= 11 No functional change. v2: Remove intel_lrc.c per Tvrtko request since those were w/a for ICL hw issuea and media related configuration. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: -
Thomas Preston authored
We rely on VBT DDI port info for eDP detection on GEN9 platforms and above. This breaks GEN9 platforms which don't have VBT because port A eDP now defaults to false. Fix this by defaulting to true when VBT is missing. Fixes: a98d9c1d ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection") Signed-off-by:
Thomas Preston <thomas.preston@codethink.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190306200618.17405-1-thomas.preston@codethink.co.uk
-
- 12 Mar, 2019 3 commits
-
-
José Roberto de Souza authored
A new PCI ID for ICL was added to BSpec, lets keep it in tight sync as ICL is not protected by the alpha support flag anymore. v2: Keeping BSpec order(Rodrigo) BSepc: 21141 Reviewed-by:
-
Chris Wilson authored
Use a timedwait to promptly detect if the recovery after reset fails and provide a meaningful debug dump. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190312111146.10662-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Move the pair of messages to the common callsite where it makes sense to include a bit more information about which request is being reset. Signed-off-by:
-
- 11 Mar, 2019 4 commits
-
-
Joonas Lahtinen authored
Merge tag 'topic/hdr-formats-2019-03-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-intel-next-queued Add support for Y21x and Y41x to drm core and i915, and P01x support to i915. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2485309-d645-bed4-95f4-e66ff312aa05@linux.intel.com
-
Joonas Lahtinen authored
To facilitate merging topic/hdr-formats from Maarten. Signed-off-by: -
Aditya Swarup authored
Setting the pixel rounding bit to 1 in PIPE_CHICKEN register allows to passthrough FB pixels unmodified across pipe. This fixes the failures for DP link layer compliance tests 4.4.1.1, 4.4.1.2 & 4.4.1.3. (Lineage #1605353570) v2: This is also needed to fix failing IGT test case kms_cursor_crc on ICL.(Mika Kahola) Make macros consistent with i915_reg.h comments.(Jani Nikula) Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190307021412.18626-1-aditya.swarup@intel.com References: https://bugs.freedesktop.org/show_bug.cgi?id=103232
-
Joonas Lahtinen authored
Signed-off-by:
-
- 09 Mar, 2019 1 commit
-
-
Chris Wilson authored
In the next patch, we will want to update live state within a context. As this state may be in use by the GPU and we haven't been explicitly tracking its activity, we instead attach it to a request we send down the context setup with its new state and on retiring that request cleanup the old state as we then know that it is no longer live. Signed-off-by:
-
- 08 Mar, 2019 22 commits
-
-
Chris Wilson authored
It is debatable whether having an error message on suspend for forcibly cancelling outstanding work is worthwhile. We want to know if it occurs in the wild (as we will then have to reconsider the approach!), but equally is not fatal across suspend, as upon resume we automatically clear the wedged status. However, CI does trigger this scenario with gem_eio/suspend; as there we are intentionally wedging the device upon suspend. The dilemma is how not to trigger a failure report for the dmesg spam, for which the quickest response is to suppress the warning in the kernel. I'd rather mark it as accepted in gem_eio, but for now detecting when gem_eio is playing games and cancelling the warning for that case seems a barely acceptable hack. Testcase: igt/gem_eio/suspend Reference: 5861b013 ("drm/i915: Do a synchronous switch-to-kernel-context on idling") Signed-off-by:
-
José Roberto de Souza authored
The support for PSR2 was polished, IGT tests for PSR2 was added and it was tested performing regular user workloads like browsing, editing documents and compiling Linux, so it is time to enable it by default and enjoy even more power-savings. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
If PSR1 is active when pipe CRC is enabled the CRC calculations will be inhibit by the transition to low power states that PSR1 brings. So lets force a PSR1 exit and as soon as pipe CRC is enabled it will block PSR1 activation and avoid CRC timeouts when running IGT tests. There is a little window between the call to force exit PSR and the write to pipe CRC registers that needs to happen within the minimum of 6 idles frames otherwise PSR1 will be active again causing the CRC timeouts but anyways this will at least reduce the occurrence of CRC timeouts. This can possibily fix issues present right now but I did not found any open, I mostly got this issue from previous CI runs of this series, bellow some exambles: * igt@kms_color@pipe-b-ctm-0-75: - shard-apl: PASS -> FAIL +9 * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy: - shard-apl: PASS -> DMESG-FAIL +17 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt: - shard-kbl: PASS -> DMESG-FAIL +12 * igt@kms_pipe_crc_basic@read-crc-pipe-c: - shard-kbl: PASS -> FAIL +7 v6: s/PSR/PSR1 (Dhinakaran) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
All of this checks are redudant and can be removed as the if bellow already takes care when there is no changes in the state. Reviewed-by:
-
José Roberto de Souza authored
When PSR2 is active aka after the number of frames programmed in PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC interrupts causing IGT tests to fail due timeout. This same behavior don't happen with PSR1, as soon as pipe CRC is enabled it blocks PSR1 activation so CRC calculation continues to happens normaly. This patch also set mode_changed as true when PSR is available to force atomic check functions to compute new PSR state, otherwise PSR2 would not be disabled. v4: Only setting mode_changed if has_psr is set(Dhinakaran) v3: Reusing intel_crtc_crc_prepare() and crc_enabled, only setting mode_changed if it can do PSR. v2: Changed commit description to describe that PSR2 inhibit CRC calculations. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
Other features like PSR2 also needs to be disabled while getting CRC so lets rename ips_force_disable to crc_enabled, drop all this checks for pipe A and HSW and BDW and make it generic and hsw_compute_ips_config() will take care of all the checks removed from here. v2: Renaming and parameter changes to the functions that prepares the commit (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
If has_psr is set it means that CRTC has a EDP panel attached so the EDP check is redundant and can be dropped. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
José Roberto de Souza authored
In any commit, intel_modeset_pipe_config() will initialilly clear and then recalculate most of the pipe states but it leave intel specific color features states in reset state. If after intel_pipe_config_compare() is detected that a fastset is possible it will mark update_pipe as true and unsed mode_changed, causing the color features state to be kept in reset state and then latter being committed to hardware disabling the color features. This issue can be reproduced by any code patch that duplicates the actual(with color features already enabled) state and only mark mode_changed as true. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
Forcing a specific CRTC to the eDP connector was causing the intel_psr_fastset_force() to mark mode_chaged in the wrong and disabled CRTC causing no update in the PSR state. Looks like our internal state track do not clear output_types and has_psr in the disabled CRTCs, not sure if this is the expected behavior or not but in the mean time this fix the issue. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Now we are checking sink capabilities when probing PSR DPCD register and then dynamically checking in if new state is compatible with PSR in, so this FIXME can be dropped. Reviewed-by:
-
Chris Wilson authored
Introduce a mutex to start locking the HW contexts independently of struct_mutex, with a view to reducing the coarse struct_mutex. The intel_context.pin_mutex is used to guard the transition to and from being pinned on the gpu, and so is required before starting to build any request. The intel_context will then remain pinned until the request completes, but the mutex can be released immediately unpin completion of pinning the context. A slight variant of the above is used by per-context sseu that wants to inspect the pinned status of the context, and requires that it remains stable (either !pinned or pinned) across its operation. By using the pin_mutex to serialise operations while pin_count==0, we can take that pin_mutex for stabilise the boolean pin status. v2: for Tvrtko! * Improved commit message. * Dropped _gpu suffix from gen8_modify_rpcs_gpu. v3: Repair the locking for sseu selftests Signed-off-by:
-
Chris Wilson authored
Each engine acquires a pin on the kernel contexts (normal and preempt) so that the logical state is always available on demand. Keep track of each engines pin by storing the returned pointer on the engine for quick access. Signed-off-by:
-
Chris Wilson authored
Push the intel_context pin callback down from intel_engine_cs onto the context itself by virtue of having a central caller for intel_context_pin() being able to lookup the intel_context itself. Signed-off-by:
-
Chris Wilson authored
In preparation for an ever growing number of engines and so ever increasing static array of HW contexts within the GEM context, move the array over to an rbtree, allocated upon first use. Unfortunately, this imposes an rbtree lookup at a few frequent callsites, but we should be able to mitigate those by moving over to using the HW context as our primary type and so only incur the lookup on the boundary with the user GEM context and engines. v2: Check for no HW context in guc_stage_desc_init Signed-off-by:
-
Chris Wilson authored
If we place a pointer to the engine specific intel_context_ops in the engine itself, we can assign the ops pointer on initialising the context, and then rely on it being set. This simplifies the code in later patches. Signed-off-by:
-
Chris Wilson authored
This complex struct pulling in half the driver deserves its own isolation in preparation for intel_context becoming an outright complicated class of its own. In order to split this beast into its own header also requests splitting several of its dependent types and their dependencies into their own headers as well. v2: Add standalone compilation tests Signed-off-by:
-
Chris Wilson authored
For use in the next patch, if we track which engines have been used by the HW, we can reduce the work required to flush our state off the HW to those engines. Signed-off-by:
-
Jani Nikula authored
Set pp_div field of struct pps_registers to INVALID_MMIO_REG when the register isn't there, and use i915_mmio_reg_valid() instead of repeating the condition all over the place. Use INVALID_MMIO_REG explicitly for documentation purposes, even if the value is unchanged from 0. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
PPS locking is a thing on pre-DDI, up to and including CPT and PPT. The PPS divisor register exists up to gen 9 BC, replaced by a field in the control register starting from gen 9 LP, i.e. BXT, GLK, and CNP on. Commit b0a08bec ("drm/i915/bxt: eDP Panel Power sequencing") stopped using the divisor register, but inadvertently conflated the PPS unlock in the change. No longer doing the unlocking was the right thing to do, however we should've stopped already at LPT (or DDI platforms). Deconflate the two. Arguably this could be moved away from here altogether, but this is the minimally intrusive change for now. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
We can no longer assume execution ordering, and in particular we cannot assume which context will execute last. One side-effect of this is that we cannot determine if the kernel-context is resident on the GPU, so remove the routines that claimed to do so. Signed-off-by:
-
Chris Wilson authored
Currently we assume that we know the order in which requests run and so can determine if we need to reissue a switch-to-kernel-context prior to idling. That assumption does not hold for the future, so instead of tracking which barriers have been used, simply determine if we have ever switched away from the kernel context by using the engine and before idling ensure that all engines that have been used since the last idle are synchronously switched back to the kernel context for safety (and else of shrinking memory while idle). v2: Use intel_engine_mask_t and ALL_ENGINES Signed-off-by:
-
Chris Wilson authored
We load a context (the kernel context) on both module load and resume in order to initialise some logical state onto the GPU. We can use the same routine for both operations, which will become more useful as we refactor rc6/rps enabling. Signed-off-by:
-
