aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-09-04drm/i915/icl: Fix context RPCS programmingTvrtko Ursulin2-13/+76
There are two issues with the current RPCS programming for Icelake: Expansion of the slice count bitfield has been missed, as well as the required programming workaround for the subslice count bitfield size limitation. 1) Bitfield width for configuring the active slice count has grown so we need to program the GEN8_R_PWR_CLK_STATE accordingly. Current code was always requesting eight times the number of slices (due writing to a bitfield starting three bits higher than it should). These requests were luckily a) capped by the hardware to the available number of slices, and b) we haven't yet exported the code to ask for reduced slice configurations. Due both of the above there was no impact from this incorrect programming but we should still fix it. 2) Due subslice count bitfield being only three bits wide and furthermore capped to a maximum documented value of four, special programming workaround is needed to enable more than four subslices. With this programming driver has to consider the GT configuration as 2x4x8, while the hardware internally translates this to 1x8x8. A limitation stemming from this is that either a subslice count between one and four can be selected, or a subslice count equaling the total number of subslices in all selected slices. In other words, odd subslice counts greater than four are impossible, as are odd subslice counts greater than a single slice subslice count. This also had no impact in the current code base due breakage from 1) always reqesting more than one slice. While fixing this we also add some asserts to flag up any future bitfield overflows. v2: * Use a local in all branches for clarity. (Lionel) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bspec: 12247 Reported-by: tony.ye@intel.com Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: tony.ye@intel.com Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903113007.2643-1-tvrtko.ursulin@linux.intel.com
2018-09-04drm/i915/ringbuffer: Move double invalidate to after pd flushChris Wilson1-18/+22
Continuing the fun of trying to find exactly the delay that is sufficient to ensure that the page directory is fully loaded between context switches, move the extra flush added in commit 70b73f9ac113 ("drm/i915/ringbuffer: Delay after invalidating gen6+ xcs") to just after we flush the pd. Entirely based on the empirical data of running failing tests in a loop until we survive a day (before the mtbf is 10-30 minutes). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107769 References: 70b73f9ac113 ("drm/i915/ringbuffer: Delay after invalidating gen6+ xcs") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904063802.13880-1-chris@chris-wilson.co.uk
2018-09-04drm/i915: Double check we didn't miss an unclaimed register accessChris Wilson1-6/+7
Currently, if the user has enabled mmio-debug around each register access, we presume that we have then checked them all. However, it is still possible through omission (raw register access) or external interaction that the unclaimed access was not highlighted. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904111732.24266-1-chris@chris-wilson.co.uk
2018-09-04drm/i915: Fix ICL+ HDMI clock readoutVille Syrjälä3-9/+17
Copy the 38.4 vs. 19.2 MHz ref clock exception from the dpll mgr into the clock readout function as well. v2: Refactor the code into a common function s/is_icl/gen11+/ (Rodrigo) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107722 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903142841.14627-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-09-03drm/i915: Use a cached mapping for the physical HWSChris Wilson3-15/+18
Older gen use a physical address for the hardware status page, for which we use cache-coherent writes. As the writes are into the cpu cache, we use a normal WB mapped page to read the HWS, used for our seqno tracking. Anecdotally, I observed lost breadcrumbs writes into the HWS on i965gm, which so far have not reoccurred with this patch. How reliable that evidence is remains to be seen. v2: Explicitly pass the expected physical address to the hw v3: Also remember the wild writes we once had for HWS above 4G. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180903152304.31589-2-chris@chris-wilson.co.uk
2018-09-03drm/i915: Combine cleanup_status_page()Chris Wilson1-14/+6
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
2018-09-03drm/i915: Fix up FORCE_GPU_RELOC (debug) to flush CPU write domainsChris Wilson1-0/+7
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903150216.19965-1-chris@chris-wilson.co.uk
2018-09-03drm/i915: Update DRIVER_DATE to 20180903Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-09-03drm/i915: Forcibly flush unwanted requests in drop-cachesChris Wilson1-16/+36
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 <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-5-chris@chris-wilson.co.uk
2018-09-03drm/i915: Early rejection of buffer allocations larger than RAMChris Wilson1-6/+19
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 <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-4-chris@chris-wilson.co.uk
2018-09-03drm/i915: Force the slow path after a user-write errorChris Wilson1-4/+5
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 <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-3-chris@chris-wilson.co.uk
2018-09-03drm/i915: Flag any possible writes for a GTT faultChris Wilson1-1/+1
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 <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-2-chris@chris-wilson.co.uk
2018-09-03drm/i915: Do a full device reset after being wedgedChris Wilson1-1/+2
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 <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-1-chris@chris-wilson.co.uk
2018-09-03drm/i915: Determine uses-full-ppgtt from context for execbufChris Wilson1-3/+6
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180901092451.7233-1-chris@chris-wilson.co.uk
2018-09-01drm/i915: Explicitly mark Global GTT address spacesTvrtko Ursulin3-1/+8
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180831143643.12366-1-tvrtko.ursulin@linux.intel.com
2018-09-01drm/i915/dp_mst: Fix enabling pipe clock for all streamsImre Deak2-8/+13
commit afb2c4437dae ("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: afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365 Reported-by: Lyude Paul <lyude@redhat.com> Reported-by: dmummenschanz@web.de Tested-by: dmummenschanz@web.de Tested-by: Lyude Paul <lyude@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: dmummenschanz@web.de Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180831174739.30387-1-imre.deak@intel.com
2018-08-31drm/i915/perf: reuse intel_lrc ctx regs macroLionel Landwerlin1-18/+16
Abstract the context image access a bit. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180813080218.28994-3-tvrtko.ursulin@linux.intel.com
2018-08-31drm/i915/perf: simplify configure all context functionLionel Landwerlin1-7/+4
We don't need any special treatment on error so just return as soon as possible. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180813080218.28994-2-tvrtko.ursulin@linux.intel.com
2018-08-31drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL.Jyoti Yadav1-3/+16
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: Imre Deak <imre.deak@intel.com> Signed-off-by: Jyoti Yadav <jyoti.r.yadav@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1535695223-4648-1-git-send-email-jyoti.r.yadav@intel.com
2018-08-31drm/i915/selftests: Add a simple exerciser for suspend/hibernateChris Wilson3-0/+223
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: 5ab57c702069 ("drm/i915: Flush logical context image out to memory upon suspend") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jakub Bartmiński <jakub.bartminski@intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Jakub Bartmiński <jakub.bartminski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180830134806.21939-1-chris@chris-wilson.co.uk
2018-08-31drm/i915: Keep physical cursors pinned while in useChris Wilson1-1/+4
The optimisation inherent in commit 6a2c4232ece1 ("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: 6a2c4232ece1 ("drm/i915: Make the physical object coherent with GTT") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180817082405.755-1-chris@chris-wilson.co.uk
2018-08-30drm/i915/ringbuffer: Delay after invalidating gen6+ xcsChris Wilson1-35/+34
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=107759 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180830161042.29193-1-chris@chris-wilson.co.uk
2018-08-30drm/i915: clear error registers after error captureLionel Landwerlin3-13/+25
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: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180830132424.21940-1-lionel.g.landwerlin@intel.com
2018-08-30drm/i915: Update DRIVER_DATE to 20180830Joonas Lahtinen1-1/+1
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-08-30drm/i915: Update DRIVER_DATE to 20180830Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-08-29drm/i915/execlists: Flush tasklet directly from reset-finishChris Wilson2-17/+6
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180828152702.27536-1-chris@chris-wilson.co.uk
2018-08-29drm/i915: Don't check power domains state in intel_power_domains_init_hw()Imre Deak1-5/+5
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: 6dfc4a8f134f ("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=107411 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180828122231.14336-1-imre.deak@intel.com
2018-08-28drm/i915/dsc: Fix PPS register definition macros for 2nd VDSC engineManasi Navare1-2/+2
This patch fixes the PPS4 and PPS5 register definition macros that were resulting into an incorect MMIO address. Fixes: 2efbb2f099fb ("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: Rodrigo Vivi <rodrigo.vivi@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
2018-08-28drm/i915: Do not advertize support for NV12 on ICL yet.Dhinakaran Pandiyan1-1/+8
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824203856.17700-2-dhinakaran.pandiyan@intel.com
2018-08-28drm/i915: Clean up skl_plane_has_planar()Dhinakaran Pandiyan1-18/+9
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: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180827225624.4912-1-dhinakaran.pandiyan@intel.com
2018-08-28drm/i915: Reject compressed Y/Yf with interlaced modesVille Syrjälä1-1/+3
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180828142707.31583-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
2018-08-28drm/i915: Don't pass plane to .check_plane()Ville Syrjälä4-12/+10
.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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180828142707.31583-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2018-08-28drm/i915: Fix gtt_view assertsVille Syrjälä2-11/+6
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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180828133723.18505-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-08-28drm/i915: Use dp_to_i915 on intel_psr.cRodrigo Vivi1-36/+14
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 <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180827223021.7145-2-rodrigo.vivi@intel.com
2018-08-28drm/i915: introduce dp_to_i915() helperRodrigo Vivi2-58/+57
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180827223021.7145-1-rodrigo.vivi@intel.com
2018-08-28drm/i915/selftests: ring all doorbells in igt_guc_doorbellsDaniele Ceraolo Spurio4-9/+59
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: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180827223614.22789-1-daniele.ceraolospurio@intel.com
2018-08-27drm/i915/psr: Rewrite comments in intel_psr_wait_for_idle()Dhinakaran Pandiyan1-14/+14
Added bspec reference, aligned text and documented the function. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824230844.12428-2-dhinakaran.pandiyan@intel.com
2018-08-27drm/i915/psr: Remove wait_for_idle() for PSR2Dhinakaran Pandiyan1-10/+6
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: c43dbcbbcc8c ("drm/i915/psr: Lockless version of psr_wait_for_idle") Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824230844.12428-1-dhinakaran.pandiyan@intel.com
2018-08-25drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"Jan-Marek Glogowski1-14/+19
This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("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 c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by: Lyude Paul <lyude@redhat.com> 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
2018-08-24drm/i915: move lookup_power_well() upPaulo Zanoni1-25/+21
There's no need for that forward declaration. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-4-paulo.r.zanoni@intel.com
2018-08-24drm/i915: use for_each_power_well in lookup_power_well()Paulo Zanoni1-8/+3
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 <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-3-paulo.r.zanoni@intel.com
2018-08-24drm/i915: WARN() if we can't lookup_power_well()Paulo Zanoni1-1/+9
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: Imre Deak <imre.deak@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-2-paulo.r.zanoni@intel.com
2018-08-24drm/i915/icl: implement the tc/legacy HPD {dis,}connect flowsPaulo Zanoni3-4/+123
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180801173441.9789-1-paulo.r.zanoni@intel.com
2018-08-23drm/i915: Free write_buf that we allocated with kzalloc.Rodrigo Vivi1-2/+6
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: 2320175feb74 ("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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180823205136.31310-1-rodrigo.vivi@intel.com
2018-08-23drm/i915: Simplify condition to keep DMC active during S0ixImre Deak1-6/+7
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822112602.27543-1-imre.deak@intel.com
2018-08-22drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLEDhinakaran Pandiyan2-5/+5
Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822015053.1420-2-dhinakaran.pandiyan@intel.com
2018-08-22drm/i915: Add a small wrapper to check for CCS modifiers.Dhinakaran Pandiyan3-12/+13
Code looks cleaner with modifiers hidden inside this wrapper. v2: Remove const qualifier (Ville) Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822193827.6341-1-dhinakaran.pandiyan@intel.com
2018-08-22drm/i915/psr: Add PSR mode/revision to debugfsAzhar Shaikh1-0/+2
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file i915_edp_psr_status. Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1534958628-193724-1-git-send-email-azhar.shaikh@intel.com
2018-08-22drm/i915: Fix glk/cnl display w/a #1175Ville Syrjälä1-3/+4
The workaround was supposed to look at the plane destination coordinates. Currently it's looking at some mixture of src and dst coordinates that doesn't make sense. Fix it up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180719182214.4323-2-ville.syrjala@linux.intel.com Fixes: 394676f05bee (drm/i915: Add WA for planes ending close to left screen edge) Reviewed-by: Imre Deak <imre.deak@intel.com>
2018-08-21drm/i915/psr: Mask PSR irq bits when re-enabling interrupts.Dhinakaran Pandiyan3-5/+5
gen8_de_irq_postinstall() wasn't masking the IRQ bit before passing the debug flag to psr_irq_control(). This check was missed when new debug bits were defined in 'commit c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6")'. Instead of ANDing the irq bit in all the callers, move it to the callee. v2: Rebased. Fixes: c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-3-dhinakaran.pandiyan@intel.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.