summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-07-06drm/i915/gtt: pde entry encoding is identicalMika Kuoppala
For all page directory entries, the pde encoding is identical. Don't complicate call sites with different versions of doing the same thing, so we always check the existence of physical page before writing the entry into it. This further generalizes the pd so that manipulation in callsites will be identical, removing the need to handle pdps differently for gen8. v2: squash v3: inc/dec with set/clear (Chris) v4: inlines, warn, stray set_pd (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> 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/20190705215204.4559-1-chris@chris-wilson.co.uk
2019-07-05drm/i915: Remove set but not used variable 'intel_dig_port'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/i915/display/intel_ddi.c: In function 'intel_ddi_get_config': drivers/gpu/drm/i915/display/intel_ddi.c:3774:29: warning: variable 'intel_dig_port' set but not used [-Wunused-but-set-variable] struct intel_digital_port *intel_dig_port; It is never used, so can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190705113138.65880-1-yuehaibing@huawei.com
2019-07-05drm/i915: Remove set but not used variable 'encoder'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/i915/display/intel_dp.c: In function 'intel_dp_set_drrs_state': drivers/gpu/drm/i915/display/intel_dp.c:6623:24: warning: variable 'encoder' set but not used [-Wunused-but-set-variable] It's never used, so can be removed.Also remove related variable 'dig_port' Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190705113112.64715-1-yuehaibing@huawei.com
2019-07-05drm/i915: Order assert forcewake testChris Wilson
Read the current value before computing the expected to ensure that if the timer does complete early (against our will), it should not cause a false positive. v2: The local irq disable did not prevent the timer from running. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111074 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/20190705074604.16496-1-chris@chris-wilson.co.uk
2019-07-05drm/i915/ehl: Add support for DPLL4 (v10)Vivek Kasireddy
This patch adds support for DPLL4 on EHL that include the following restrictions: - DPLL4 cannot be used with DDIA (combo port A internal eDP usage). DPLL4 can be used with other DDIs, including DDID (combo port A external usage). - DPLL4 cannot be enabled when DC5 or DC6 are enabled. - The DPLL4 enable, lock, power enabled, and power state are connected to the MGPLL1_ENABLE register. v2: (suggestions from Bob Paauwe) - Rework ehl_get_dpll() function to call intel_find_shared_dpll() and iterate twice: once for Combo plls and once for MG plls. - Use MG pll funcs for DPLL4 instead of creating new ones and modify mg_pll_enable to include the restrictions for EHL. v3: Fix compilation error v4: (suggestions from Lucas and Ville) - Treat DPLL4 as a combo phy PLL and not as MG PLL - Disable DC states when this DPLL is being enabled - Reuse icl_get_dpll instead of creating a separate one for EHL v5: (suggestion from Ville) - Refcount the DC OFF power domains during the enabling and disabling of this DPLL. v6: rebase v7: (suggestion from Imre) - Add a new power domain instead of iterating over the domains assoicated with DC OFF power well. v8: (Ville and Imre) - Rename POWER_DOMAIN_DPLL4 TO POWER_DOMAIN_DPLL_DC_OFF - Grab a reference in intel_modeset_setup_hw_state() if this DPLL was already enabled perhaps by BIOS. - Check for the port type instead of the encoder v9: (Ville) - Move the block of code that grabs a reference to the power domain POWER_DOMAIN_DPLL_DC_OFF to intel_modeset_readout_hw_state() to ensure that there is a reference present before this DPLL might get disabled. v10: rebase Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: 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/20190703230353.24059-1-vivek.kasireddy@intel.com
2019-07-05drm/i915: Clean up skl vs. icl plane formatsVille Syrjälä
Split the format lists for different planes on skl/icl more cleanly. On skl+ we have just two types of planes: those can do planar and those that can't. On icl we have three types of planes: hdr planes, sdr planes that can do planar, and sdr planes that can't do planar. Those latter two are the same set of planes we must when choose from when picking the UV vs. Y plane for planar scanout. So we shall just designate them sdr uv planes and sdr y planes. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-7-ville.syrjala@linux.intel.com
2019-07-05drm/i915: Cosmetic fix for skl+ plane switch statementVille Syrjälä
One of the switch cases has the byte order vs. format bits reversed to all the other cases. Appease the ocd and reorder them. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-6-ville.syrjala@linux.intel.com
2019-07-05drm/i915: Deal with cpp==8 for g4x watermarksVille Syrjälä
Docs tell us that on g4x we have to compute the SR watermarks using 4 bytes per pixel. I'm going to assume that only applies to 1 and 2 byte per pixel formats, and not 8 byte per pixel formats. That seems like a recipe for an insufficient watermark which could lead to underruns. Use the maximum of the two numbers instead. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-5-ville.syrjala@linux.intel.com
2019-07-05drm/i915: Program plane gamma rampsVille Syrjälä
All sprite planes have a progammable gamma ramp. Set it up with a linear ramp on all platforms. This actually matches the reset value but soon we'll want to reprogram this ramp on some machines, so let's just set it up across the board. Note that on pre-IVB the hardware bypasses the gamma unit unless a YCbCr pixel format is used. v2: Add parens around << in ilk_linear_gamma() Skip gamma programming for RGB on pre-IVB s/DVSGAMC/DVSGAMC_G4X/ Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-4-ville.syrjala@linux.intel.com
2019-07-05drm/i915: Disable sprite gamma on ivb-bdwVille Syrjälä
We don't currently have any use for the sprite gamma on ivb-bdw. Let's disable it. We already do that on skl+. On pre-ivb there is no way to disable the sprite gamma, and it only affects YCbCr pixel formats, whereas on ivb+ it also affects RGB formats. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-3-ville.syrjala@linux.intel.com
2019-07-05drm/i915: Add windowing for primary planes on gen2/3 and chvVille Syrjälä
Plane B and C (note that we don't actually expose plane C currently) on gen2/3 have a window generator, as does the primary plane on CHV pipe B. So let's allow positioning of these planes freely within the pipe source area. Plane A on gen2/3 seems to have some kind of partial window generator which would allow you to cut the plane off midway through the scanout, but it would still have to start at the top-left corner of the pipe, and it would have to be full width. That's doesn't sound all that useful, so for simplicity let's just keep to the idea that plane A has to be fullscreen. Gen4 removed the plane A/B windowing support entirely, and it wasn't reintroduced until SKL (apart from the CHV pipe B special case). v2: s/plane/i9xx_plane/ etc. (James) v3: Make it less confusing v4: Deal with IS_GEN() Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-2-ville.syrjala@linux.intel.com
2019-07-05drm/i915: Move dev_priv->pm_i{m, e}r into intel_gtTvrtko Ursulin
PM interrupts belong to the GT so move the variables to be inside struct intel_gt. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-3-tvrtko.ursulin@linux.intel.com
2019-07-05drm/i915: Remove some legacy mmio accessors from interrupt handlingTvrtko Ursulin
Mostly in gen11 interrupt handling and a couple neighbouring functions which were easy since uncore local was already available. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-2-tvrtko.ursulin@linux.intel.com
2019-07-05drm/i915: Rework some interrupt handling functions to take intel_gtTvrtko Ursulin
Some interrupt handling functions already have gt in their names suggesting them as obvious candidates to make them take struct intel_gt instead of i915. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-1-tvrtko.ursulin@linux.intel.com
2019-07-04drm/i915: Show instdone for each engine in debugfsChris Wilson
Although polling each engine quickly is preferable as it should give us a sample of each engine at roughly the same time, keep it simple and just sample the engine as print out the debug state. 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/20190704200455.14870-3-chris@chris-wilson.co.uk
2019-07-04drm/i915/selftests: Be engine agnosticChris Wilson
When using MI operations, we do not care which engine we use, so use them all where possible, and where inconvenient double check we have the engine we selected at random. v2: Drop the local copy of engine->sseu to avoid an unchecked deref 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/20190704212343.6820-1-chris@chris-wilson.co.uk
2019-07-04drm/i915/overlay: Stash the kernel context on initialisationChris Wilson
Simplify runtime request creation by storing the context we need to use during initialisation. This allows us to remove one more hardcoded engine lookup. 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/20190704200455.14870-1-chris@chris-wilson.co.uk
2019-07-04drm/i915/hangcheck: Look at instdone for all enginesTvrtko Ursulin
It seems intel_engine_get_instdone is able to get instdone for all engines but intel_hangcheck.c/subunits_stuck decides to ignore it for non render. We can just drop the check in subunits_stuck since the checks on unavailable fields will always return stuck, which when bitwise and with the potential unstuck instdone is harmless. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> 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/20190703144116.15593-1-tvrtko.ursulin@linux.intel.com
2019-07-04drm/i915/selftests: Drain the freedlists between exec passesChris Wilson
During the context execution tests, we issue a lot of work and discard a lot of objects without releasing the lock and allowing the background reaper to free those objects. Insert a small break between each pass to flush the worker. 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/20190704165317.21060-1-chris@chris-wilson.co.uk
2019-07-04drm/i915/gtt: Mark the freed page table entries with scratchChris Wilson
On unwinding the allocation error path and having freed the page table entry, it is imperative that we mark it as scratch. <4> [416.075569] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [416.075801] CPU: 0 PID: 2385 Comm: kworker/u2:11 Tainted: G U 5.2.0-rc7-CI-Patchwork_13534+ #1 <4> [416.076162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014 <4> [416.076522] Workqueue: i915 __i915_vm_release [i915] <4> [416.076754] RIP: 0010:gen8_ppgtt_cleanup_3lvl+0x58/0xb0 [i915] <4> [416.077023] Code: 81 e2 04 fe ff ff 81 c2 ff 01 00 00 4c 8d 74 d6 58 4d 8b 65 00 4d 3b a7 28 02 00 00 74 40 49 8d 5c 24 50 49 81 c4 50 10 00 00 <48> 8b 2b 49 3b af 20 02 00 00 74 13 4c 89 ff 48 89 ee e8 01 fb ff <4> [416.077445] RSP: 0018:ffffc9000046bd98 EFLAGS: 00010206 <4> [416.077625] RAX: 0001000000000000 RBX: 6b6b6b6b6b6b6bbb RCX: 8b4b56d500000000 <4> [416.077838] RDX: 00000000000001ff RSI: ffff88805a578008 RDI: ffff88805bd0efc8 <4> [416.078167] RBP: ffff88805bd0efc8 R08: 0000000004e42b93 R09: 0000000000000001 <4> [416.078381] R10: 0000000000000000 R11: ffff888077a1b0b8 R12: 6b6b6b6b6b6b7bbb <4> [416.078594] R13: ffff88805a578058 R14: ffff88805a579058 R15: ffff88805bd0efc8 <4> [416.078815] FS: 0000000000000000(0000) GS:ffff88807da00000(0000) knlGS:0000000000000000 <4> [416.079395] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [416.079851] CR2: 000056160fec2b14 CR3: 0000000071bbc003 CR4: 00000000003606f0 <4> [416.080388] Call Trace: <4> [416.080828] gen8_ppgtt_cleanup+0x64/0x100 [i915] <4> [416.081399] __i915_vm_release+0xfc/0x1d0 [i915] Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704201656.15775-1-chris@chris-wilson.co.uk
2019-07-04drm/i915/gt: Pull engine w/a initialisation into commonChris Wilson
We need to setup the workarounds on all engines, with the knowledge about which platforms each workaround applies to kept together in the workaround list. As such, we can pull the w/a initialisation into the common setup and try to avoid duplicating knowledge about when to setup the workarounds. 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/20190703135805.7310-2-chris@chris-wilson.co.uk
2019-07-04drm/i915: Dump w/a lists on all enginesChris Wilson
We store separate wa_list on every engine, so be sure to include all when dumping the current set via debugfs. 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/20190703135805.7310-1-chris@chris-wilson.co.uk
2019-07-04drm/i915/guc: Upgrade to GuC 33.0.0Michal Wajdeczko
New GuC firmware is available. Let's use it. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190703113640.31100-1-michal.wajdeczko@intel.com
2019-07-04drm/i915/gtt: Handle double alloc failuresChris Wilson
Matthew pointed out that we could face a double failure with concurrent allocations/frees, and so the assumption that the local var alloc was NULL was fraught with danger. Rather than complicate the error paths too much to add a second local for a second free, just do the second free earlier on the unwind path. Reported-by: Matthew Auld <matthew.william.auld@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704104345.6603-1-chris@chris-wilson.co.uk
2019-07-04drm/i915: Show support for accurate sw PMU busyness trackingChris Wilson
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
2019-07-04drm/i915/gem: Defer obj->base.resv fini until RCU callbackChris Wilson
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: c03467ba40f7 ("drm/i915/gem: Free pages before rcu-freeing the object") Testcase: igt/gem_busy/close-race Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703180601.10950-1-chris@chris-wilson.co.uk
2019-07-04drm/i915/gt: Ignore forcewake acquisition for posting_readsChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-4-chris@chris-wilson.co.uk
2019-07-04drm/i915/gt: Assume we hold forcewake for execlists resumeChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-3-chris@chris-wilson.co.uk
2019-07-04drm/i915/gt: Use caller provided forcewake for intel_mocs_init_engineChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-2-chris@chris-wilson.co.uk
2019-07-04drm/i915: Check caller held wakerefs in assert_forcewakes_activeChris Wilson
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: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704102048.6436-1-chris@chris-wilson.co.uk
2019-07-04drm/i915: Flush the workqueue before drainingChris Wilson
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=110550 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703171913.16585-4-chris@chris-wilson.co.uk
2019-07-04drm/i915: Move the renderstate setup under gt/Chris Wilson
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 <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/20190704091925.7391-1-chris@chris-wilson.co.uk
2019-07-04drm/i915/gtt: Defer the free for alloc error pathsChris Wilson
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: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703171913.16585-3-chris@chris-wilson.co.uk
2019-07-04Merge tag 'drm-next-5.3-2019-06-27' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.3-2019-06-27: amdgpu: - Fix warning on 32 bit ARM - Fix compilation on big endian - Misc bug fixes ttm: - Live lock fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628015555.3384-1-alexander.deucher@amd.com
2019-07-04Merge tag 'drm-misc-next-fixes-2019-06-27' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next-fixes for v5.3: - Fixes to the tfp410 bridge. - Small build fix for vga_switcheroo to prevent building against modular fbcon. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20a62234-bc27-00eb-e0e2-22b55eec1cb2@linux.intel.com
2019-07-04Merge tag 'for-airlie-armada' of git://git.armlinux.org.uk/~rmk/linux-arm ↵Dave Airlie
into drm-next Armada DRM updates: - Fix interlace support. - use __drm_atomic_helper_plane_reset in overlay reset. - since the overlay and video planes use essentially the same format registers, precompute their values while validating. - fix a long-standing deficiency with overlay planes and interlace modes - calculate plane starting address at atomic_check stage rather than when we're programming the registers. - add gamma support. - ensure mode adjustments made by other components are properly handled in the driver and applied to the CRTC-programmed mode. - add and use register definitions for the "REG4F" register. - use drm_atomic_helper_shutdown() when tearing down to ensure that the hardware is properly shutdown. - add CRTC-level mode validation to ensure that we don't allow a mode that the CRTC-level hardware can not support. - improve the clocking selection for Armada 510 support. - move CRTC debugfs files into the crtc-specific directory, using the DRM helper to create these files. - patch from Lubomir Rintel to replace a simple framebuffer. - use the OF graph walker rather than open-coding this. - eliminate a useless check for the availability of the remote's parent which isn't required. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Russell King <rmk@armlinux.org.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190702091313.GA23442@rmk-PC.armlinux.org.uk
2019-07-04Merge tag 'exynos-drm-next-for-v5.3' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next - Drop the use of drmP.h header file drmP.h header file has been deprecated so this patch drops the use of this header, and instead includes appropriate header files required. - Add COMPILE_TEST flag This patch adds COMPILE_TEST dependency to exynos drm driver to increase build test coverage. And also, it includes vmalloc.h header file to fix one build warning which is introduced when building the Linux kernel using sh. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAAQKjZMdBdD8oEa0cNv78FjrpOqu20ozTTvuPEm_XnVo2gRhCQ@mail.gmail.com
2019-07-03drm/i915: Add N & CTS values for 10/12 bit deep colorAditya Swarup
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
2019-07-03drm/i915: Use port clock to set correct N valueAditya Swarup
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: 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-1-aditya.swarup@intel.com
2019-07-03drm/i915: Deal with machines that expose less than three QGV pointsVille Syrjälä
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: c457d9cf256e ("drm/i915: Make sure we have enough memory bandwidth on ICL") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110838 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606124210.3482-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2019-07-03drm/i915: Mark up vma->active as safe for use inside shrinkersChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-8-chris@chris-wilson.co.uk
2019-07-03drm/i915: Markup potential lock for i915_activeChris Wilson
Make the lockchains more deterministic via i915_active by flagging the potential lock. 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/20190703091726.11690-7-chris@chris-wilson.co.uk
2019-07-03drm/i915/gem: Free pages before rcu-freeing the objectChris Wilson
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: a93615f900bd ("drm/i915: Throw away the active object retirement complexity") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-6-chris@chris-wilson.co.uk
2019-07-03drm/i915/execlists: Hesitate before slicingChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-9-chris@chris-wilson.co.uk
2019-07-03drm/i915/selftests: Lock the drm_mm while modifyingChris Wilson
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 <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-2-chris@chris-wilson.co.uk
2019-07-03drm/i915/selftests: Common live setup/teardownChris Wilson
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 <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-1-chris@chris-wilson.co.uk
2019-07-03drm/i915/display: Handle lost primary_port across suspendChris Wilson
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: 24a7bfe0c2d7 ("drm/i915: Keep the TypeC port mode fixed when the port is active") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190702140950.7069-1-chris@chris-wilson.co.uk
2019-07-03drm/i915: synchronize_irq() against the actual irqVille Syrjälä
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: Imre Deak <imre.deak@intel.com> Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111012 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190702151723.29739-1-ville.syrjala@linux.intel.com
2019-07-02drm/i915/gtt: Don't check PPGTT presence on PPGTT-only platformsMichał Winiarski
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: 4bdafb9ddfa4 ("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: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190702113149.21200-2-michal.winiarski@intel.com
2019-07-02Revert "drm/i915: Introduce private PAT management"Michał Winiarski
This reverts commit 4395890a48551982549d222d1923e2833dac47cf. 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: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> 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/20190702113149.21200-1-michal.winiarski@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 19:46:47 +0000