- 04 Jul, 2019 9 commits
-
-
Chris Wilson authored
Expose whether or not we support the PMU software tracking in our scheduler capabilities, so userspace can query at runtime. v2: Use I915_SCHEDULER_CAP_ENGINE_BUSY_STATS for a less ambiguous capability name. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703143702.11339-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since reservation_object_fini() does an immediate free, rather than kfree_rcu as normal, we have to delay the release until after the RCU grace period has elapsed (i.e. from the rcu cleanup callback) so that we can rely on the RCU protected access to the fences while the object is a zombie. i915_gem_busy_ioctl relies on having an RCU barrier to protect the reservation in order to avoid having to take a reference and strong memory barriers. v2: Order is important; only release after putting the pages! Fixes: c03467ba ("drm/i915/gem: Free pages before rcu-freeing the object") Testcase: igt/gem_busy/close-race Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703180601.10950-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We don't care about the result of the read, so it may be garbage, we only care that the mmio is flushed. As such, we can forgo using an individual forcewake and lock around any posting-read for an engine. Signed-off-by:
-
Chris Wilson authored
We can assume the caller is holding a blanket forcewake for the register writes during resume, and so we can skip taking individual locks around each write inside execlists resume. Signed-off-by:
-
Chris Wilson authored
During post-reset resume, we call intel_mocs_init_engine to reinitialise the MOCS registers. Suprisingly, especially when enhanced by lockdep, the acquisition of the forcewake lock around each register write takes a substantial portion of the reset time. We don't need to use the individual forcewake here as we can assume that the caller is holding a blanket forcewake for the reset&resume and the resume is serialised. Signed-off-by:
-
Chris Wilson authored
The intent of the assert is to document that the caller took the appropriate wakerefs for the function. However, as Tvrtko pointed out, we simply check whether the fw_domains are active and may be confused by the auto wakeref which may be dropped between the check and use. Let's be more careful in the assert and check that each fw_domain has an explicit caller wakeref above and beyond the automatic wakeref. v2: Fix spelling for config DRM_I915_DEBUG_RUNTIME_PM v3: Timer may still be active after we drop the autowakeref, we need to check domain->active instead. v4: The timer checks domain->active, but we still need to check the timer. (This is starting to look weird...) Reported-by:
-
Chris Wilson authored
Trying to drain a workqueue while we may still be adding to it from background tasks is, according to kernel/workqueue.c, verboten. So, add a flush_workqueue() at the start of our cleanup procedure. References: https://bugs.freedesktop.org/show_bug.cgi?id=110550Signed-off-by:
-
Chris Wilson authored
The render state is used to initialise the default RCS context, and only used during early setup from within the gt code. As such, it makes a good candidate for placing within gt/, even if it is not yet entirely clean of our GEM heritage. Signed-off-by:
-
Chris Wilson authored
If we hit an error while allocating the page tables, we have to unwind the incomplete updates, and wish to free the unused pd. However, we are not allowed to be hoding the spinlock at that point, and so must use the later free to defer it until after we drop the lock. <3> [414.363795] BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/i915_gem_gtt.c:472 <3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: i915_selftest <4> [414.364406] 3 locks held by i915_selftest/3905: <4> [414.364408] #0: 0000000034fe8aa8 (&dev->mutex){....}, at: device_driver_attach+0x18/0x50 <4> [414.364415] #1: 000000006bd8a560 (&dev->struct_mutex){+.+.}, at: igt_ctx_exec+0xb7/0x410 [i915] <4> [414.364476] #2: 000000003dfdc766 (&(&pd->lock)->rlock){+.+.}, at: gen8_ppgtt_alloc_pdp+0x448/0x540 [i915] <3> [414.364529] Preemption disabled at: <4> [414.364530] [<0000000000000000>] 0x0 <4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U 5.2.0-rc7-CI-CI_DRM_6403+ #1 <4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014 <4> [414.364699] Call Trace: <4> [414.364704] dump_stack+0x67/0x9b <4> [414.364708] ___might_sleep+0x167/0x250 <4> [414.364777] vm_free_page+0x24/0xc0 [i915] <4> [414.364852] free_pd+0xf/0x20 [i915] <4> [414.364897] gen8_ppgtt_alloc_pdp+0x489/0x540 [i915] <4> [414.364946] gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915] <4> [414.364992] ppgtt_bind_vma+0x2e/0x60 [i915] <4> [414.365039] i915_vma_bind+0xe8/0x2c0 [i915] <4> [414.365088] __i915_vma_do_pin+0xa1/0xd20 [i915] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111050 Fixes: 1d1b5490 ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by:
-
- 03 Jul, 2019 11 commits
-
-
Aditya Swarup authored
Adding N & CTS values for 10/12 bit deep color from Appendix C table in HDMI 2.0 spec. The correct values for N is not chosen automatically by hardware for deep color modes. v2: Remove unnecessary initialization of size Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190627220708.31700-2-aditya.swarup@intel.com
-
Aditya Swarup authored
Use port_clock to check the clock values in n/cts lookup table instead of crtc_clock. As port_clock is already adjusted based on color mode set (8 bit or deep color), this will help in checking clock values for deep color modes from n/cts lookup table. Signed-off-by:
-
Ville Syrjälä authored
When SAGV is forced to disabled/min/med/max in the BIOS pcode will only hand us a single QGV point instead of the normal three. Fix the code to deal with that instead declaring the bandwidth limit to be 0 MB/s (and thus preventing any planes from being enabled). Also shrink the max_bw sturct a bit while at it, and change the deratedbw type to unsigned since the code returns the bw as an unsigned int. Since we now keep track of how many qgv points we got from pcode we can drop the earlier check added for the "pcode doesn't support the memory subsystem query" case. Cc: felix.j.degrood@intel.com Cc: Mark Janes <mark.a.janes@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Fixes: c457d9cf ("drm/i915: Make sure we have enough memory bandwidth on ICL") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110838Signed-off-by:
Matt Roper <matthew.d.roper@intel.com>
-
Chris Wilson authored
Since a shrinker may be forced to wait on GPU activity, i915_active_wait(&vma->active) must be safe for use inside a shrinker, and so let's mark up the lock as being acquired by the shrinker to avoid any nasty surprises creeping in. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-8-chris@chris-wilson.co.uk
-
Chris Wilson authored
Make the lockchains more deterministic via i915_active by flagging the potential lock. Signed-off-by:
-
Chris Wilson authored
As we have dropped the final reference to the object, we do not need to wait until after the rcu grace period to drop its pages. We still require struct_mutex to completely unbind the object to release the pages, so we still need a free-worker to manage that from process context. By scheduling the release of pages before waiting for the rcu should mean that we are not trapping those pages from beyond the reach of the shrinker. v2: Pass along the request to skip if the vma is busy to the underlying unbind routine, to avoid checking the reservation underneath the i915->mm.obj_lock which may be used from inside irq context. v3: Flip the bit for unbinding while active, for later convenience. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111035 Fixes: a93615f9 ("drm/i915: Throw away the active object retirement complexity") Signed-off-by:
-
Chris Wilson authored
Be a little more hesitant before injecting a timeslice, and try to take into account any change in priority that is due for the running task before switching to another task. This will allow us to arbitrarily prevent switching away from a request if we deem it necessarily to disable preemption, for instance. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-9-chris@chris-wilson.co.uk
-
Chris Wilson authored
Remember to lock the drm_mm as we modify it, lest it be modified in the background by retire/free workers! Signed-off-by:
-
Chris Wilson authored
We frequently, but not frequently enough!, remember to flush residual operations and objects at the end of a live subtest. The purpose is to cleanup after every subtest, leaving a clean slate for the next subtest, and perform early detection of leaky state. As this should ideally be common for all live subtests, pull the task into a common teardown routine. Signed-off-by:
-
Chris Wilson authored
icl-dsi is dying on suspend/resume at RIP: 0010:icl_update_active_dpll+0x2c/0xa0 [i915] which appears due to the loss of the time primary_port across suspend. Protect against the potential NULL dereference by assuming ICL_PORT_DPLL_DEFAULT unless the port is actively specified otherwise. Fixes: 24a7bfe0 ("drm/i915: Keep the TypeC port mode fixed when the port is active") Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190702140950.7069-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
When eliminating our use of drm_irq_install() I failed to convert all our synchronize_irq() calls to consult pdev->irq instead of dev_priv->drm.irq. As we no longer populate dev_priv->drm.irq we're no longer synchronizing against anything. v2: Add intel_syncrhonize_irq() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
-
- 02 Jul, 2019 7 commits
-
-
Michał Winiarski authored
We missed one place where we check PPGTT-only platform for PPGTT presence. Let's remove it. While I'm here let's assert that this particular code is never called on pre-gen8 platforms. References: 4bdafb9d ("drm/i915: Remove i915.enable_ppgtt override") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michał Winiarski authored
This reverts commit 4395890a. It's been over a year since this was merged, and the actual users of intel_ppat_get / intel_ppat_put never materialized. Time to remove it! v2: Unbreak suspend (Chris) v3: Rebase, drop fixes tag to avoid confusion Signed-off-by:
-
Mika Kuoppala authored
If we untrack wakerefs, the actual count may reach zero. However the krealloced owners array is still there and needs to be taken care of. Free the owners unconditionally to fix the leak. Fixes: bd780f37 ("drm/i915: Track all held rpm wakerefs") Reported-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Lionel Landwerlin authored
The same tests failing on CFL+ platforms are also failing on ICL. Documentation doesn't list the WaAllowPMDepthAndInvocationCountAccessFromUMD workaround for ICL but applying it fixes the same tests as CFL. v2: Use only one whitelist entry (Lionel) Signed-off-by:
Anuj Phogat <anuj.phogat@gmail.com> Cc: stable@vger.kernel.org Acked-by:
-
Lionel Landwerlin authored
CFL:C0+ changed the status of those registers which are now blacklisted by default. This is breaking a number of CTS tests on GL & Vulkan : KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations (GL) dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.* (Vulkan) v2: Only use one whitelist entry (Lionel) Bspec: 14091 Signed-off-by:
-
Lionel Landwerlin authored
When a register is readonly there is not much we can tell about its value (apart from its default value?). This can be covered by tests exercising the value of the register from userspace. For PS_INVOCATION_COUNT we've got the following piglit tests : KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations Vulkan CTS tests : dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.* v2: Use a local to shrink under 80cols. Signed-off-by:
-
Chris Wilson authored
If we try to wait on an i915_active from within a critical section, it will remain busy (such as if we are shrinking from within i915_active_ref). Report the failure so that we do not proceed thinking it is idle. Extracted from a future patch "drm/i915: Coordinate i915_active with its own mutex". Fixes: 12c255b5 ("drm/i915: Provide an i915_active.acquire callback") Signed-off-by:
-
- 01 Jul, 2019 13 commits
-
-
Chris Wilson authored
Daniele pointed out that the CSB status information will change with Tigerlake and suggested that we could rearrange our state machine to hide the differences in generation. gcc also prefers the explicit state machine, so make it so: process_csb 1980 1967 -13 Suggested-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
Although EHL added a third combo PHY, no PHY_MISC register was added for PHY C. The bspec indicates that there's no need to program the "DE to IO Comp Pwr Down" setting for this PHY that we usually need to set in PHY_MISC. v2: - Add IS_ELKHARTLAKE() guards since future platforms that have a PHY C are likely to reinstate the PHY_MISC register. (Jose) - Use goto's to skip PHY_MISC programming & minimize code deltas. (Jose) Bspec: 33148 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Matt Roper authored
v2: Rename register to _EHL_COMBOPHY_C. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Matt Roper authored
The port parameter hasn't been used since the last bspec phy programming update. Drop it to make some upcoming changes simpler. References: 9659c1af ("drm/i915/icl: combo port vswing programming changes per BSPEC") Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-2-matthew.d.roper@intel.com
-
Chris Wilson authored
During reset, we must be very selective in which locks we take as most are tainted by being held across a wait or reclaim (kmalloc) which implicitly waits. Inside the guc reset path, we reset the ADS to sane defaults, but must keep it pinned from initialisation to avoid having to pin it during reset. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190701100502.15639-1-chris@chris-wilson.co.uk
-
Imre Deak authored
Lane reversal happens only in the FIA module for TBT-alt/DP-alt mode, so WARN if lane reversal is attempted at a different level. See the BSpec DDI_BUF_CTL register description. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
Disconnecting the TypeC PHY when the port is in legacy mode is not necessary: - BSpec doesn't specify a disconnect sequence for legacy mode. - The use of the PHY is dedicated for the display in legacy mode. - We keep the PHY always connected during runtime as well in legacy mode. We disconnect the PHY when needed during a disabling modeset for the port, so we can also remove the disconnect call from the destroy hook. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
Add state verification for the TypeC port mode wrt. the port's AUX power well enabling/disabling. Also check the correctness of changing the port mode: - When enabling/disabling the AUX power well for a TypeC port we must hold the TypeC port lock - the case for AUX transfers - or hold a Type C port link reference - the case for modeset enabling/disabling. - When changing the TypeC port mode the port's AUX power domain must be disabled. v2: (Ville) - Simplify power_well_async_ref_count(). - Fix the commit log, clarifying what are the valid conditions to enable/disable the AUX power wells. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
The TypeC port mode needs to stay fixed whenever the port is active. Do that by introducing a tc_link_refcount to account for active ports, avoiding changing the port mode if a reference is held. During the modeset commit phase we also have to reset the port mode and update the active PLL reflecting the new port mode. We can do this only once the port and its old PLL has been already disabled. Add the new encoder update_prepare/complete hooks that are called around the whole enabling sequence. The TypeC specific hooks of these will reset the port mode, update the active PLL if the port will be active and ensure that the port mode will stay fixed for the duration of the whole enabling sequence by holding a tc_link_refcount. During the port enabling, the pre_pll_enable/post_pll_disable hooks will take/release a tc_link_refcount to ensure the port mode stays fixed while the port is active. Changing the port mode should also be avoided during connector detection and AUX transfers if the port is active, we'll do that by checking the port's tc_link_refcount. When resetting the port mode we also have to take into account the maximum lanes provided by the FIA. It's guaranteed to be 4 in TBT-alt and legacy modes, but there may be less lanes available in DP-alt mode, in which case we have to fall back to TBT-alt mode. While at it also update icl_tc_phy_connect()'s code comment, reflecting the current way of switching the port mode. v2: - Add the update_prepare/complete hooks to the encoder instead of the connector. (Ville) - Simplify intel_connector_needs_modeset() by removing redundant if. (Ville) v3: - Fix sparse warning, marking static functions as such. v4: - Rebase on drm-tip. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Imre Deak authored
When enabling a TypeC port we need to reserve all the required PLLs for it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks. We can select the proper PLL for the current port mode from the reserved PLLs only once we selected and locked down the port mode for the whole duration of the port's active state. Resetting and locking down the port mode can in turn happen only during the modeset commit phase once we disabled the given port and the PLL it used. To support the above reserve-and-select PLL semantic we store the reserved PLLs along with their HW state in the CRTC state and provide a way to select the active PLL from these. The selected PLL along with its HW state will be pointed at by crtc_state->shared_dpll/dpll_hw_state as in the case of other port types. Besides reserving all required PLLs no functional changes. v2: - Fix releasing the ICL PLLs, not clearing the PLLs from the old crtc_state. - Init port_dpll to ICL_PORT_DPLL_DEFAULT closer to where port_dpll is used for symmetry with the corresponding ICL_PORT_DPLL_MG_PHY init. (Ville) v3: - Add FIXME: for clearing the ICL port PLLs from the new crtc state. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Imre Deak authored
For clarity factor out the combo PHY and TypeC PHY specific code from icl_get_dplls() into their own functions. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Pass the PLL HW state to the PLL find/reference functions making it clearer what is their input. Also pass to these the atomic state and the CRTC object instead of the CRTC state, since they don't require the latter. Move setting the PLL in the crtc_state to the get_dpll() hook, which is the more logical place for this, where the related PLL HW state was also set. This refactoring is also a preparation for a follow-up patch that will have to find/reference multiple PLLs. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Imre Deak authored
For consistency s/intel_get_shared_dpll()/intel_reserve_shared_dplls()/ to better match intel_release_shared_dplls(). Also, pass to the reserve/release and get_dplls/put_dplls hooks the intel_atomic_state and CRTC object, that way these functions can look up the old or new state as needed. Also release the PLLs from the atomic state via a new put_dplls->intel_unreference_shared_dpll() call chain for better symmetry with the reservation via the get_dplls->intel_reference_shared_dpll() call chain. Since nothing uses the PLL returned by intel_reserve_shared_dplls(), make it return only a bool. While at it also clarify the reserve/release function docbook headers making it clear that multiple DPLLs will be reserved/released and whether the new or old atomic CRTC state is affected. This refactoring is also a preparation for a follow-up change that needs to reserve multiple DPLLs. Kudos to Ville for the idea to pass intel_atomic_state around, to make things clearer locally where an object's old/new atomic state is required. No functional changes. v2: - Fix checkpatch issue: typo in code comment. v3: - Rebase on drm-tip. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
