- 03 Sep, 2018 9 commits
-
-
Chris Wilson authored
Pull the physical status page cleanup into a common cleanup_status_page() for caller simplicity. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903152304.31589-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We currently assert that if the target is in a CPU write domain, we use a CPU reloc path rather than the GPU reloc path. However, we have a debug override to force the GPU path and that unfortunately hits the assert. Include the async clflush under the debug option to ensure correct behaviour even when debugging, and strict when not. Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
Add a mode to debugfs/drop-caches to flush unwanted requests off the GPU (by wedging the device and resetting). This is very useful if a test terminated leaving a long queue of hanging batches that would ordinarily require a round trip through hangcheck for each. It reduces the inter-test operation to just a write into drop-caches to reset driver/GPU state between tests. Signed-off-by:
-
Chris Wilson authored
We currently try to pin and allocate the whole buffer at a time. If that object is larger than RAM, we will try to pin the whole of physical memory, force the machine into oom, and then still fail the allocation. If the request is obviously too large, error out early. We opt to do this in the backend to make it easy to use alternate paths that do not require the entire object pinned, or may easily handle proxy objects that are larger than physical memory. Signed-off-by:
-
Chris Wilson authored
If we fail to write the user relocation back when it is changed, force ourselves to take the slow relocation path where we can handle faults in the write path. There is still an element of dubiousness as having patched up the batch to use the correct offset, it no longer matches the presumed_offset in the relocation, so a second pass may miss any changes in layout. Signed-off-by:
-
Chris Wilson authored
We do not explicitly mark the PTE for the user's GTT mmap as being wrprotect, so we don't get a refault when we would need to change a read-only mmapping into read-write. As such, we must presume that if the vma has PROT_WRITE it may be written to, although this is supposed to be indicated by set-domain there are cases (e.g. after swap) where userspace may not be aware of the implicit domain change. Signed-off-by:
-
Chris Wilson authored
We only call unset_wedged on the global reset path (since it's a global operation), so if we are terminally wedged and wish to reset, take the full device reset path rather than the quicker individual engine resets. Signed-off-by:
-
Chris Wilson authored
Rather than inspect the global module parameter for whether full-ppgtt maybe enabled, we can inspect the context directly as to whether it has its own vm. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180901092451.7233-1-chris@chris-wilson.co.uk
-
- 01 Sep, 2018 2 commits
-
-
Tvrtko Ursulin authored
So far we have been relying on vm->file pointer being NULL to declare something GGTT. This has the unfortunate consequence that the default kernel context is also declared GGTT and interferes with the following patch which wants to instantiate VMA's and execute requests against the kernel context. Change the is_ggtt test to use an explicit flag in struct address_space to solve this issue. Note that the bit used is free since there is an alignment hole in the struct. v2: * Mark mock ggtt. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Imre Deak authored
commit afb2c443 ("drm/i915/ddi: Push pipe clock enabling to encoders") inadvertently stopped enabling the pipe clock for any DP-MST stream after the first one. It also rearranged the pipe clock enabling wrt. initial MST payload allocation step (which may or may not be a problem, but it's contrary to the spec.). Fix things by making the above commit truly a non-functional change. Fixes: afb2c443 ("drm/i915/ddi: Push pipe clock enabling to encoders") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365Reported-by:
Lyude Paul <lyude@redhat.com> Reported-by: dmummenschanz@web.de Tested-by: dmummenschanz@web.de Tested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 31 Aug, 2018 5 commits
-
-
Lionel Landwerlin authored
Abstract the context image access a bit. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
We don't need any special treatment on error so just return as soon as possible. Signed-off-by:
-
Jyoti Yadav authored
This patch resolves the DMC FW loading issue. Earlier DMC FW package have only one DMC FW for one stepping. But as such there is no such restriction from Package side. For ICL icl_dmc_ver1_07.bin binary package has DMC FW for 2 steppings. So while reading the dmc_offset from package header, for 1st stepping offset used to come 0x0 and was working fine till now. But for second stepping and other steppings, offset is non zero number and is in dwords. So we need to convert into bytes to fetch correct DMC FW from correct place. v2 : Added check for DMC FW max size for various gen. (Imre Deak) v3 : Corrected naming convention for various gen. (Imre Deak) v4 : Initialized max_fw_size to 0 v5 : Corrected DMC FW MAX_SIZE for various gen. (Imre Deak) v6 : Fixed the typo issues. Reviewed-by:
Jyoti Yadav <jyoti.r.yadav@intel.com> Signed-off-by:
-
Chris Wilson authored
Although we cannot do a full system-level test of suspend/hibernate from deep with the kernel selftests, we can exercise the GEM subsystem in isolation and simulate the external effects (such as losing stolen contents and trashing the register state). v2: Don't forget to hold rpm v3: Suspend the GTT mappings, and more rpm! References: https://bugs.freedesktop.org/show_bug.cgi?id=96526 References: 5ab57c70 ("drm/i915: Flush logical context image out to memory upon suspend") Signed-off-by:
Jakub Bartmiński <jakub.bartminski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180830134806.21939-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The optimisation inherent in commit 6a2c4232 ("drm/i915: Make the physical object coherent with GTT") relies on that once we allocated a cursor we would have coherent, zero overhead access to the scanout plane holding the cursor. That is we could then do the very frequent cursor updates X enjoys with no indirection or kernel involvement. However, that all hinges on the GGTT mmap of the cursor being pinned and not require refaulting on each access -- handling such a page fault likely requires the busy GGTT to be rearranged causing a stall. A very simple fix is then to handle the physical cursor exactly like other cursors and keep its vma pinned while active. References: https://bugs.freedesktop.org/show_bug.cgi?id=107600 References: 6a2c4232 ("drm/i915: Make the physical object coherent with GTT") Signed-off-by:
-
- 30 Aug, 2018 4 commits
-
-
Chris Wilson authored
During stress testing of full-ppgtt (on Baytrail at least), we found that the invalidation around a context/mm switch was insufficient (writes would go astray). Adding a second MI_FLUSH_DW barrier prevents this, but it is unclear as to whether this is merely a delaying tactic or if it is truly serialising with the TLB invalidation. Either way, it is empirically required. v2: Avoid the loop for readability; Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107715 References: https://bugs.freedesktop.org/show_bug.cgi?id=107759Signed-off-by:
-
Lionel Landwerlin authored
We need to clear the register in order to get correct value after the next potential hang. v2: Centralize error register clearing in i915_irq.c (Chris) v3: Don't read gen8 register on < gen6 (Chris) v4: Don't swap gen8+ & gen6+ code... (Chris) Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by: -
Joonas Lahtinen authored
Signed-off-by:
-
- 29 Aug, 2018 2 commits
-
-
Chris Wilson authored
On finishing the reset, the intention is to restart the GPU before we relinquish the forcewake taken to handle the reset - the goal being the GPU reloads a context before it is allowed to sleep. For this purpose, we used tasklet_flush() which although it accomplished the goal of restarting the GPU, carried with it a sting in its tail: it cleared the TASKLET_STATE_SCHED bit. This meant that if another CPU queued a new request to this engine, we would clear the flag and later attempt to requeue the tasklet on the local CPU, breaking the per-cpu softirq lists. Remove the dangerous tasklet_kill() and just run the tasklet func directly as we know it is safe to do so (the tasklets are internally locked to allow mixed usage from direct submission). Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180828152702.27536-1-chris@chris-wilson.co.uk
-
Imre Deak authored
During power domains initialization we acquire power well references for power wells in the INIT power domain. The rest of power wells - which BIOS could have left enabled - we can only acquire references as needed during display HW readout and so must defer sanitization until then (also implying that we must always do HW readout to cleanup unused power wells). Thus during initialization these latter power wells can have a refcount of 0 while still being enabled. To avoid the false-positive state mismatch error this causes remove the check from intel_power_domains_init_hw() and rely on the state check in intel_power_domains_enable() which follows the HW readout. v2: - Add comment to log and code clarifying how unused power wells get disabled. (Chris) Fixes: 6dfc4a8f ("drm/i915: Verify power domains after enabling them") Cc: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=107411Signed-off-by:
-
- 28 Aug, 2018 9 commits
-
-
Manasi Navare authored
This patch fixes the PPS4 and PPS5 register definition macros that were resulting into an incorect MMIO address. Fixes: 2efbb2f0 ("i915/dp/dsc: Add DSC PPS register definitions") Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824014807.14681-1-manasi.d.navare@intel.com
-
Dhinakaran Pandiyan authored
ICL requires two planes for scanning out a NV12 framebuffer. Do not advertize support for creating NV12 framebuffers until required plane programming is implemented. v2: Do not allow adding buffers. Check inside skl_plane_has_planar (Ville) Bspec: Plane Planar YUV programming (18566) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
skl_plane_has_planar is hard to read, simplify the logic by checking for support in the order of platform, pipe and plane. No change in functionality intended. v2: Fix logic for primary plane (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Y/Yf tiling can't be used with IF-ID. We already reject uncompressed Y/Yf but we should also reject them when compressed. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
-
Ville Syrjälä authored
.check_plane() already gets the plane state, so we can dig out the plane from there if needed. No need in passing it separately. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Ville Syrjälä authored
gcc is too smart for us and doesn't evaluate BUILD_BUG_ON()s in unused static inlines. Collect them up in one static inline and actually call it to make sure gcc sees it. Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
-
Rodrigo Vivi authored
Now that we have a generic caller let's simplify it and clean up the intel_psr.c code a bit. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
No functional change. But let's get first i915 pointer directly from intel_dp so we can clean up a lot of code later. Signed-off-by:
-
Daniele Ceraolo Spurio authored
We currently verify that all doorbells can be registered with GuC and HW but don't check that all works as expected after a db ring. Do a nop ring of all doorbells to make sure we haven't misprogrammed any WQ or stage descriptor data. This will also help validating upcoming changes in the db programming flow. Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Acked-by:
Katarzyna Dec <katarzyna.dec@intel.com> Signed-off-by:
-
- 27 Aug, 2018 2 commits
-
-
Dhinakaran Pandiyan authored
Added bspec reference, aligned text and documented the function. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
CI runs show PSR2 does not go to IDLE with selective update enabled on all PSR exit triggers. Specifically, logs indicate the hardware enters "SLEEP Selective Update" and not "IDLE Reset state', like the kernel expects, when vblank interrupts are enabled. This check was added for PSR1 but incorrectly extended to PSR2, remove the check as it breaks tests and prints out misleading error messages. v2: Split out non-code changes (Rodrigo) Cc: Tarun Vyas <tarun.vyas@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: c43dbcbb ("drm/i915/psr: Lockless version of psr_wait_for_idle") Signed-off-by:
-
- 25 Aug, 2018 1 commit
-
-
Jan-Marek Glogowski authored
This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147b ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by:
Jan-Marek Glogowski <glogow@fbihome.de> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.com
-
- 24 Aug, 2018 4 commits
-
-
Paulo Zanoni authored
There's no need for that forward declaration. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-4-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
Use the nice helper function to make the implementation simpler. v2: Rebase. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Signed-off-by:
-
Paulo Zanoni authored
None of the current lookup_power_well() callers are actually checking for NULL return values, they all just use the pointer right away. The first idea was to replace these theoretical segfaults with a BUG() since this would at least make our code a little more explicit to the reader. It was suggested that just converting the BUG() to a WARN() and returning any power well would probably be better since it would still keep the system running while at the same time exposing the driver bug. We can only hit this NULL/BUG()/WARN() condition if we try to lookup a power well that isn't defined on a given platform. If that ever happens, we have to fix our code, making it lookup the correct power well. Because of this, I don't think it's worth trying to implement error checking in every caller. Improving our CI system will be a better use of our time once a bug is found in the wild. v2: Avoid the BUG() with a WARN() return a random PW (Michal). Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Paulo Zanoni authored
Unlike the other ports, TC ports are not available to use as soon as we get a hotplug. The TC PHYs can be shared between multiple controllers: display, USB, etc. As a result, handshaking through FIA is required around connect and disconnect to cleanly transfer ownership with the controller and set the type-C power state. This patch implements the flow sequences described by our specification. We opt to grab ownership of the ports as soon as we get the hotplugs in order to simplify the interactions and avoid surprises in the user space side. We may consider changing this in the future, once we improve our testing capabilities on this area. v2: * This unifies the DP and HDMI patches so we can discuss everything at once so people looking at random single patches can actually understand the direction. * I found out the spec was updated a while ago. There's a small difference in the connect flow and the patch was updated for that. * Our spec also now gives a good explanation on what is really happening. As a result, comments were added. * Add some more comments as requested by Rodrigo (Rodrigo). v3: * Downgrade a DRM_ERROR that shouldn't ever happen but we can't act on in case it does (Chris). BSpec: 21750, 4250. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 23 Aug, 2018 2 commits
-
-
Rodrigo Vivi authored
We use kzalloc to allocate the write_buf that we use for i2c transfer on hdcp write. But it seems that we are forgetting to free the memory that is not needed after i2c transfer is completed. Reported-by:
Brian J Wood <brian.j.wood@intel.com> Fixes: 2320175f ("drm/i915: Implement HDCP for HDMI") Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by:
-
Imre Deak authored
For S0ix we want to deinit power domains (and so deactivate the DMC firmware) exactly when the platform supports the DC9 state. To reach S0ix we need DC9 on these platforms (for which the DMC FW needs to be deactivated) while to reach S0ix on the rest of the DMC platforms we need DC6 (which needs the DMC FW to stay active). Simplify the condition accordingly so it will be automatically correct for upcoming DC9 platforms like ICL. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
