- 05 7月, 2019 19 次提交
-
-
由 Chris 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=111074Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190705074604.16496-1-chris@chris-wilson.co.uk
-
由 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: NVivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703230353.24059-1-vivek.kasireddy@intel.com
-
由 Ville 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-7-ville.syrjala@linux.intel.com
-
由 Ville 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-6-ville.syrjala@linux.intel.com
-
由 Ville 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-5-ville.syrjala@linux.intel.com
-
由 Ville 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-4-ville.syrjala@linux.intel.com
-
由 Ville 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-3-ville.syrjala@linux.intel.com
-
由 Ville 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703200824.5971-2-ville.syrjala@linux.intel.com
-
由 Tvrtko Ursulin 提交于
PM interrupts belong to the GT so move the variables to be inside struct intel_gt. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-3-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
Mostly in gen11 interrupt handling and a couple neighbouring functions which were easy since uncore local was already available. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-2-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko 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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-1-tvrtko.ursulin@linux.intel.com
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704200455.14870-3-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704212343.6820-1-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704200455.14870-1-chris@chris-wilson.co.uk
-
由 Tvrtko 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: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190703144116.15593-1-tvrtko.ursulin@linux.intel.com
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704165317.21060-1-chris@chris-wilson.co.uk
-
由 Chris 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: 1d1b5490 ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704201656.15775-1-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703135805.7310-2-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703135805.7310-1-chris@chris-wilson.co.uk
-
- 04 7月, 2019 14 次提交
-
-
由 Michal Wajdeczko 提交于
New GuC firmware is available. Let's use it. Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190703113640.31100-1-michal.wajdeczko@intel.com
-
由 Chris 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: NMatthew Auld <matthew.william.auld@gmail.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704104345.6603-1-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703143702.11339-1-chris@chris-wilson.co.uk
-
由 Chris 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: c03467ba ("drm/i915/gem: Free pages before rcu-freeing the object") Testcase: igt/gem_busy/close-race Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703180601.10950-1-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-4-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-3-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703155225.9501-2-chris@chris-wilson.co.uk
-
由 Chris 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: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704102048.6436-1-chris@chris-wilson.co.uk
-
由 Chris 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=110550Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703171913.16585-4-chris@chris-wilson.co.uk
-
由 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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704091925.7391-1-chris@chris-wilson.co.uk
-
由 Chris 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: 1d1b5490 ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703171913.16585-3-chris@chris-wilson.co.uk
-
由 Aditya 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: NAditya 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: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190627220708.31700-2-aditya.swarup@intel.com
-
由 Aditya 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: NAditya 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: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190627220708.31700-1-aditya.swarup@intel.com
-
由 Ville 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: c457d9cf ("drm/i915: Make sure we have enough memory bandwidth on ICL") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110838Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606124210.3482-1-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>
-
- 03 7月, 2019 7 次提交
-
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-8-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Make the lockchains more deterministic via i915_active by flagging the potential lock. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-7-chris@chris-wilson.co.uk
-
由 Chris 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: a93615f9 ("drm/i915: Throw away the active object retirement complexity") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-6-chris@chris-wilson.co.uk
-
由 Chris 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: NChris 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: NLionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-9-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-2-chris@chris-wilson.co.uk
-
由 Chris 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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-1-chris@chris-wilson.co.uk
-
由 Chris 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: 24a7bfe0 ("drm/i915: Keep the TypeC port mode fixed when the port is active") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NImre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190702140950.7069-1-chris@chris-wilson.co.uk
-