- 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:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190309160250.29324-1-chris@chris-wilson.co.uk
-
- 08 Mar, 2019 25 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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308000050.6226-9-jose.souza@intel.com
-
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:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190305135215.29862-2-jani.nikula@intel.com
-
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:
-
Chris Wilson authored
When the system idles, we switch to the kernel context as a defensive measure (no users are harmed if the kernel context is lost). Currently, we issue a switch to kernel context and then come back later to see if the kernel context is still current and the system is idle. However, if we are no longer privy to the runqueue ordering, then we have to relax our assumptions about the logical state of the GPU and the only way to ensure that the kernel context is currently loaded is by issuing a request to run after all others, and wait for it to complete all while preventing anyone else from issuing their own requests. v2: Pull wedging into switch_to_kernel_context_sync() but only after waiting (though only for the same short delay) for the active context to finish. Signed-off-by:
-
Chris Wilson authored
Check that we have setup on preemption for the engine before testing, instead warn if it is not enabled on supported HW. Signed-off-by:
-
Imre Deak authored
Pretend that we have only 1 DBuf slice and that 1 slice is always enabled, until we have a proper way for on-demand toggling of the second slice. Currently we'll try to incorrectly enable DBuf even when all pipes are disabled and we are already runtime suspended (as the computed number of DBuf slices will be 1 in that case). This also means we'll leave the second slice enabled redundantly (except when suspended), but that's an acceptable tradeoff until we have a proper solution. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108756 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
- 07 Mar, 2019 10 commits
-
-
Chris Wilson authored
We can reduce the switch-to-kernel-context selftest to operate as a loop and so trivially test another state transition (that of idle->busy). Signed-off-by:
-
Ville Syrjälä authored
We'll need to know the memory type in the system for some bandwidth limitations and whatnot. Let's read that out on gen9+. v2: Rebase v3: Fix the copy paste fail in the BXT bit definitions (Jani) Reviewed-by:
-
Ville Syrjälä authored
We'll need information about the memory configuration on cnl+ too. Extend the code to parse the slightly changed register layout. v2: Document what cnl_get_dimm_size() returns (Jani) Reviewed-by:
-
Ville Syrjälä authored
Remove the pointless zero initialization of bunch of things (the thing is kzalloc()ed). Also throw out the mostly useless on-stack string. I think it'll be clear enough from the logs that 0 means unknown. Reviewed-by:
-
Ville Syrjälä authored
Rename the dimm info structs for clarity. Reviewed-by:
-
Ville Syrjälä authored
Decouple intel_is_dram_symmetric() from the raw register values by comparing just the dram_channel_info structs. Reviewed-by:
-
Ville Syrjälä authored
Reduce the code duplication a bit by sharing the same code for parsing both DIMMs on a channel. v2: s/%d/%u/ all over (Jani) Reviewed-by:
-
Ville Syrjälä authored
The BXT code for parsing DIMM info works for GLK too. Let's dig it out even if we might not need it immediately. Reviewed-by:
-
Ville Syrjälä authored
The BXT DUNIT register tells us the size of each DRAM device in Gb. We want to report the size of the whole DIMM in GB, so that it matches how we report it for non-LP platforms. v2: Deobfuscate the math (Chris) s/GB/GBIT/ in the register bit definitions (Jani) Reviewed-by: -
Ville Syrjälä authored
Polish the bxt DIMM parsing by extracting a few small helpers. v2: Use struct dram_dimm_info v3: Document what bxt_get_dimm_size() returns (Jani) Reviewed-by:
-
