- 02 May, 2019 1 commit
-
-
Stanislav Lisovskiy authored
Currently due to regression CI machine displays show corrupt picture. Problem is when CDCLK is as low as 79200, picture gets unstable, while DSI and DE pll values were confirmed to be correct. Limiting to 158400 as agreed with Ville. We could not come up with any better solution yet, as PLL divider values both for MIPI(DSI PLL) and CDCLK(DE PLL) are correct, however seems that due to some boundary conditions, when clocking is too low we get wrong timings for DSI display. Similar workaround exists for VLV though, so just took similar condition into use. At least that way GLK platform will start to be usable again, with current drm-tip. v2: Fixed commit subject as suggested. v3: Added generic bugs(crc failures, screen not init for GLK DSI which might be affected). v4: Added references tag for bugs affected. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=109267 References: https://bugs.freedesktop.org/show_bug.cgi?id=103184Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190430125119.7478-1-stanislav.lisovskiy@intel.com
-
- 01 May, 2019 2 commits
-
-
Chris Wilson authored
The workqueue code complains viciously if we try to queue more work onto the queue while attampting to drain it. As we asynchronously free objects and defer their enqueuing with RCU, it is quite tricky to quiesce the system before attempting to drain the workqueue. Yet drain we must to ensure that the worker is idle before unloading the module. Give the freed object drain 3 whole passes with multiple rcu_barrier() to give the defer freeing of several levels each protected by RCU and needing a grace period before its parent can be freed, ultimately resulting in a GEM object being freed after another RCU period. A consequence is that it will make module unload even slower. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110550Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190501135753.8711-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Make the engine responsible for cleaning itself up! This removes the i915->gt.cleanup vfunc that has been annoying the casual reader and myself for the last several years, and helps keep a future patch to add more cleanup tidy. v2: Assert that engine->destroy is set after the backend starts allocating its own state. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190501103204.18632-1-chris@chris-wilson.co.uk
-
- 30 Apr, 2019 27 commits
-
-
Ville Syrjälä authored
The pipe has a special HDR mode with higher precision when only HDR planes are active. Let's use it. Curiously this fixes the kms_color gamma/degamma tests when using a HDR plane, which is always the case unless one hacks the test to use an SDR plane. If one does hack the test to use an SDR plane it does pass already. I have no actual explanation how the output after the gamma LUT can be different between the two modes. The way the tests are written should mean that the output should be identical between the solid color vs. the gradient. But clearly that somehow doesn't hold true for the HDR planes in non-HDR pipe mode. Anyways, as long as we stick to one type of plane the test should produce sensible results now. v2: s/HDR_MODE/HDR_MODE_PRECISION/ (Shashank) Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Tested-by:
Shashank Sharma <shashank.sharma@intel.com>
-
Ville Syrjälä authored
Move the platform checks out from haswell_set_pipemisc() and rename it to bdw_set_pipemisc() to make it clear when to call it. Signed-off-by:
-
Chris Wilson authored
When the system is idling, contention for struct_mutex should be low and so we will be more efficient to wait for a contended mutex than reschedule. Signed-off-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
Commit 696173b0 ("drm/i915: extract intel_pm.h from intel_drv.h") missed the declarations in i915_drv.h. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: fix sparse warnings on undeclared global functions Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the header remains self-contained, and do so with minimal further includes, using forward declarations as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: fix sparse warnings on undeclared global functions Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
Keep the header self-contained. It'll need rework of its own in the future, but gotta start somewhere. Reviewed-by:
-
Jani Nikula authored
And ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Put the header more in line with the rest. No functional changes. Reviewed-by:
-
Jani Nikula authored
Just a types include required. Reviewed-by:
-
Jani Nikula authored
Add more headers to the header test list: * i915_drv.h * i915_params.h * i915_reg.h * intel_drv.h * intel_uncore.h Happily they already are self-contained, but keep them that way. Reviewed-by:
-
Lucas De Marchi authored
Separate the two comments: one is a workaround and the other is a sanity check. We could just compare != 1, but let's treat them differently due to having different meaning. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190404230426.15837-4-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Reorder if/else so we check for gen >= 11 first, similar to most of other checks in the driver. Signed-off-by:
-
Lucas De Marchi authored
At some point the spec was changed and we never updated the numbers to match it. Let's try once more to keep them in sync. Signed-off-by:
-
Tvrtko Ursulin authored
WaEnableStateCacheRedirectToCS context workaround configures the L3 cache to benefit 3d workloads but media has different requirements. Remove the workaround and whitelist the register to allow any userspace configure the behaviour to their liking. v2: * Remove the workaround apart from adding the whitelist. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by:
Anuj Phogat <anuj.phogat@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190418100634.984-1-tvrtko.ursulin@linux.intel.com Fixes: f63c7b48 ("drm/i915/icl: WaEnableStateCacheRedirectToCS") Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> [tursulin: Anuj reported no GPU hangs or performance regressions with old Mesa on patched kernel.]
-
- 29 Apr, 2019 1 commit
-
-
Chris Wilson authored
If the context has not been used yet, it needs no barrier, and in the process fix up the selftest in mock_contexts. Testcase: igt/gem_ctx_clone/vm Signed-off-by:
-
- 26 Apr, 2019 9 commits
-
-
Chris Wilson authored
Having transitioned GEM over to using intel_context as its primary means of tracking the GEM context and engine combined and using i915_request_create(), we can move the older i915_request_alloc() helper function into selftests/ where the remaining users are confined. Signed-off-by:
-
Chris Wilson authored
We no longer need to track the active intel_contexts within each engine, allowing us to drop a tricky mutex_lock from inside unpin (which may occur inside fs_reclaim). Signed-off-by:
-
Chris Wilson authored
We switched to a tree of per-engine HW context to accommodate the introduction of virtual engines. However, we plan to also support multiple instances of the same engine within the GEM context, defeating our use of the engine as a key to looking up the HW context. Just allocate a logical per-engine instance and always use an index into the ctx->engines[]. Later on, this ctx->engines[] may be replaced by a user specified map. v2: Add for_each_gem_engine() helper to iterator within the engines lock v3: intel_context_create_request() helper v4: s/unsigned long/unsigned int/ 4 billion engines is quite enough. v5: Push iterator locking to caller Signed-off-by:
-
Chris Wilson authored
In the next patch, we require the engine vfuncs setup prior to initialising the pinned kernel contexts, so split the vfunc setup from the engine initialisation and call it earlier. v2: s/setup_xcs/setup_common/ for intel_ring_submission_setup() Signed-off-by:
-
Chris Wilson authored
Move the intel_context_instance() to the caller so that we can decouple ourselves from one context instance per engine. v2: Rename pin_lock() to lock_pinned(), hopefully that is clearer. Signed-off-by:
-
Chris Wilson authored
Combine the (i915_gem_context, intel_engine) into a single parameter, the intel_context for convenience and later simplification. Signed-off-by:
-
Chris Wilson authored
Simply the setup slightly for the sseu selftests to use the actual kernel_context. Signed-off-by:
-
Chris Wilson authored
We want to pass in a intel_context into intel_context_pin() and that requires us to first be able to lookup the intel_context! Signed-off-by:
-
Chris Wilson authored
Our eventual goal is to rid request construction of struct_mutex, with the short term step of lifting the struct_mutex requirements into the higher levels (i.e. the caller must ensure that the context is already pinned into the GTT). In this patch, we pin GVT's shadow context upon allocation and so keep them pinned into the GGTT for as long as the virtual machine is alive, and so we can use the simpler request construction path safe in the knowledge that the hard work is already done. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426163336.15906-1-chris@chris-wilson.co.uk
-
