summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-10-04drm/i915/guc: Don't clear the cookie on doorbell destroyDaniele Ceraolo Spurio
If the HW has not processed the db invalidation request yet, clearing the cookie can generate a db ring. We clear the cookie when we (re-)allocate the doorbell so no need to do it on destroy as well as no one is going to look at it while the doorbell is inactive v2: fix typo in patch title (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181002215430.15049-2-daniele.ceraolospurio@intel.com
2018-10-04drm/i915/guc: init GuC descriptors after GuC loadDaniele Ceraolo Spurio
GuC stores some data in there, which might be stale after a reset. We already reset the WQ head and tail, but more things are being moved to the descriptor with the interface updates. Instead of trying to track them one by one, always memset and init the descriptors from scratch after GuC is loaded. The code is also reorganized so that the above operations and the doorbell creation are grouped as "client enabling" v2: add proc_desc_fini for symmetry (Daniele), remove unneeded var init, add guc_is_alive() (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181002215430.15049-1-daniele.ceraolospurio@intel.com
2018-10-03drm/i915/execlists: Flush the CS events before unpinningChris Wilson
Inside the execlists submission tasklet, we often make the mistake of assuming that everything beneath the request is available for use. However, the submission and the request live on two separate timelines, and the request contents may be freed from an early retirement before we have had a chance to run the submission tasklet (think ksoftirqd). To safeguard ourselves against any mistakes, flush the tasklet before we unpin the context if execlists still has a reference to this context. v2: Pull hw_context->active tracking into schedule_in and schedule_out. References: 60367132a214 ("drm/i915: Avoid use-after-free of ctx in request tracepoints") 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/20181003110941.27886-1-chris@chris-wilson.co.uk
2018-10-03drm/i915: Clear the error PTE just once on finishChris Wilson
We do not need to continually clear our dedicated PTE for error capture as it will be updated and invalidated to the next object. Only at the end do we wish to be sure that the PTE doesn't point back to any buffer. 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/20181001194447.29910-3-chris@chris-wilson.co.uk
2018-10-03drm/i915: Handle incomplete Z_FINISH for compressed error statesChris Wilson
The final call to zlib_deflate(Z_FINISH) may require more output space to be allocated and so needs to re-invoked. Failure to do so in the current code leads to incomplete zlib streams (albeit intact due to the use of Z_SYNC_FLUSH) resulting in the occasional short object capture. v2: Check against overrunning our pre-allocated page array v3: Drop Z_SYNC_FLUSH entirely Testcase: igt/i915-error-capture.js Fixes: 0a97015d45ee ("drm/i915: Compress GPU objects in error state") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.10+ Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181003082422.23214-1-chris@chris-wilson.co.uk
2018-10-03drm/i915/selftests: Hold task_struct ref for smoking kthreadChris Wilson
As the kthread may terminate itself, the parent must hold a task_struct reference for it to call kthread_stop(). <4> [498.827675] stack segment: 0000 [#1] PREEMPT SMP PTI <4> [498.827683] CPU: 0 PID: 3872 Comm: drv_selftest Tainted: G U 4.19.0-rc6-CI-CI_DRM_4915+ #1 <4> [498.827686] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018 <4> [498.827695] RIP: 0010:kthread_stop+0x36/0x210 <4> [498.827698] Code: 05 df 3d f6 7e 89 c0 48 0f a3 05 95 f8 29 01 0f 82 56 01 00 00 f0 ff 43 20 f6 43 26 20 0f 84 7f 01 00 00 48 8b ab b0 05 00 00 <f0> 80 4d 00 02 48 89 df e8 5d ff ff ff 48 89 df e8 15 c7 00 00 48 <4> [498.827701] RSP: 0018:ffffc900003937d0 EFLAGS: 00010202 <4> [498.827704] RAX: 0000000000000001 RBX: ffff8802165ece40 RCX: 0000000000000001 <4> [498.827707] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffffffff82247460 <4> [498.827709] RBP: 6b6b6b6b6b6b6b6b R08: 00000000581395cb R09: 0000000000000001 <4> [498.827711] R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000393868 <4> [498.827713] R13: ffffc900003937f0 R14: ffff88026c068040 R15: 0000000000001057 <4> [498.827716] FS: 00007fc0c464b980(0000) GS:ffff880277e00000(0000) knlGS:0000000000000000 <4> [498.827718] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [498.827720] CR2: 000056178c2feca0 CR3: 000000026983c000 CR4: 0000000000340ef0 <4> [498.827723] Call Trace: <4> [498.827824] smoke_crescendo+0x14c/0x1d0 [i915] <4> [498.827837] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [498.827898] ? __i915_gem_context_pin_hw_id+0x69/0x5f0 [i915] <4> [498.827902] ? ida_alloc_range+0x1f2/0x3d0 <4> [498.827907] ? __mutex_unlock_slowpath+0x46/0x2b0 <4> [498.827914] ? rcu_lockdep_current_cpu_online+0x8f/0xd0 <4> [498.827979] live_preempt_smoke+0x2c2/0x470 [i915] <4> [498.828047] __i915_subtests+0x5e/0xf0 [i915] <4> [498.828113] __run_selftests+0x10b/0x190 [i915] <4> [498.828175] i915_live_selftests+0x2c/0x60 [i915] <4> [498.828232] i915_pci_probe+0x50/0xa0 [i915] <4> [498.828238] pci_device_probe+0xa1/0x130 <4> [498.828244] really_probe+0x25d/0x3c0 <4> [498.828249] driver_probe_device+0x10a/0x120 <4> [498.828253] __driver_attach+0xdb/0x100 <4> [498.828256] ? driver_probe_device+0x120/0x120 <4> [498.828259] bus_for_each_dev+0x74/0xc0 <4> [498.828264] bus_add_driver+0x15f/0x250 <4> [498.828268] ? 0xffffffffa00c3000 <4> [498.828271] driver_register+0x56/0xe0 <4> [498.828274] ? 0xffffffffa00c3000 <4> [498.828278] do_one_initcall+0x58/0x2e0 <4> [498.828281] ? rcu_lockdep_current_cpu_online+0x8f/0xd0 <4> [498.828285] ? do_init_module+0x1d/0x1ea <4> [498.828289] ? rcu_read_lock_sched_held+0x6f/0x80 <4> [498.828293] ? kmem_cache_alloc_trace+0x264/0x290 <4> [498.828297] do_init_module+0x56/0x1ea <4> [498.828302] load_module+0x26f5/0x29d0 <4> [498.828309] ? vfs_read+0x122/0x140 <4> [498.828318] ? __se_sys_finit_module+0xd3/0xf0 <4> [498.828321] __se_sys_finit_module+0xd3/0xf0 <4> [498.828329] do_syscall_64+0x55/0x190 <4> [498.828332] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [498.828335] RIP: 0033:0x7fc0c3f16839 Fixes: 992d2098ef0b ("drm/i915/selftests: Split preemption smoke test into threads") 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/20181002132927.7669-1-chris@chris-wilson.co.uk
2018-10-02drm/i915/psr: Enable PSR1 on gen-9+ HWDhinakaran Pandiyan
We have new tests and fixes in place since the feature was last disabled. Try again for gen-9+ hardware and enable only PSR1 by default as a first step. v2: Remove typo fix and comment improvements (Rodrigo) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> References: commit 2ee7dc497e34 ("drm/i915: disable PSR by default on HSW/BDW") References: commit dcb2e993f3c0 ("Revert "drm/i915: Enable PSR by default on Valleyview and Cherryview."") Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Tested-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180928061117.12394-1-dhinakaran.pandiyan@intel.com
2018-10-02drm/i915: fix wrong error number reportAndi Shyti
During driver load it's considered that the i915_driver_create() function fails only in case of insufficient memory. Indeed, in case of failure of i915_driver_create(), the load function returns indiscriminately -ENOMEM ignoring the real cause of failure. In i915_driver_create() get the consistent error value from drm_dev_init() and embed it in the pointer return value. Signed-off-by: Andi Shyti <andi.shyti@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/20181002092047.14705-1-andi.shyti@intel.com
2018-10-02drm/i915: Show actual alongside requested frequency in ↵Chris Wilson
debugfs/i915_rps_boost_info Previously we hesitated in adding the hw probe for the actual GPU frequency for rps_boost as it is quite cumbersome, but given some surprising HW behaviour it would be useful to know both the RPS boost state and the actual HW state in one location. v2: vlv/chv needs more tlc Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181002113221.29208-1-chris@chris-wilson.co.uk
2018-10-02drm/i915: Replace some open-coded i915_coherent_map_type()Chris Wilson
A few callsites were deciding on using WC or WB maps based on HAS_LLC(), so replace them with the equivalent helper function i915_coherent_map_type(). 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/20181001194447.29910-1-chris@chris-wilson.co.uk
2018-10-02drm/i915: Add plane alpha blending support, v2.Maarten Lankhorst
Add plane alpha blending support with the different blend modes. This has been tested on a icl to show the correct results, on earlier platforms small rounding errors cause issues. But this already happens case with fully transparant or fully opaque RGB8888 fb's. The recommended HW workaround is to disable alpha blending when the plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending). This is easy to implement on any platform, so just do that. The tests for userspace are also available, and pass on gen11. Changes since v1: - Change mistaken < 0xff0 to 0xff00. - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend mode. - Rework disabling FBC when per pixel alpha is used. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mlankhorst: Change MISSING_CASE default to explicit alpha disable (mattrope)] Link: https://patchwork.freedesktop.org/patch/msgid/20180815103405.22679-1-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2018-10-02drm/i915/csr: Added ICL Stepping infoJyoti Yadav
As DMC Package contain DMC FW for multiple steppings including default stepping. This patch will help to load FW for that particular stepping, if FW for that stepping is available, instead of loading default FW. v2 : Fix formatting issue. Signed-off-by: Jyoti Yadav <jyoti.r.yadav@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1536169347-31326-1-git-send-email-jyoti.r.yadav@intel.com
2018-10-01drm/i915: Priority boost for waiting clientsChris Wilson
Latency is in the eye of the beholder. In the case where a client stops and waits for the gpu, give that request chain a small priority boost (not so that it overtakes higher priority clients, to preserve the external ordering) so that ideally the wait completes earlier. v2: Tvrtko recommends to keep the boost-from-user-stall as small as possible and to allow new client flows to be preferred for interactivity over stalls. Testcase: igt/gem_sync/switch-default Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181001144755.7978-3-chris@chris-wilson.co.uk
2018-10-01drm/i915: Pull scheduling under standalone lockChris Wilson
Currently, the backend scheduling code abuses struct_mutex into order to have a global lock to manipulate a temporary list (without widespread allocation) and to protect against list modifications. This is an extraneous coupling to struct_mutex and further can not extend beyond the local device. Pull all the code that needs to be under the one true lock into i915_scheduler.c, and make it so. 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/20181001144755.7978-2-chris@chris-wilson.co.uk
2018-10-01drm/i915: Priority boost for new clientsChris Wilson
Taken from an idea used for FQ_CODEL, we give the first request of a new request flows a small priority boost. These flows are likely to correspond with short, interactive tasks and so be more latency sensitive than the longer free running queues. As soon as the client has more than one request in the queue, further requests are not boosted and it settles down into ordinary steady state behaviour. Such small kicks dramatically help combat the starvation issue, by allowing each client the opportunity to run even when the system is under heavy throughput load (within the constraints of the user selected priority). v2: Mark the preempted request as the start of a new flow, to prevent a single client being continually gazumped by its peers. Testcase: igt/benchmarks/rrul Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181001144755.7978-1-chris@chris-wilson.co.uk
2018-10-01drm/i915: Pass intel_encoder to infoframe functionsVille Syrjälä
Make life simpler by passing around intel_encoder instead of drm_encoder. @r1@ identifier F =~ "infoframe"; identifier I, M; @@ F( - struct drm_encoder *I + struct intel_encoder *I , ...) { <... ( - I->M + I->base.M | - I + &I->base ) ...> } @r2@ identifier F =~ "infoframe"; identifier I; type T, ST; @@ ST { ... T (*F)( - struct drm_encoder *I + struct intel_encoder *encoder , ...); ... }; @@ identifier r1.F; expression E; @@ F( - E + to_intel_encoder(E) ,...) @@ identifier r2.F; expression E, X; @@ ( X.F( - E + to_intel_encoder(E) ,...) | X->F( - E + to_intel_encoder(E) ,...) ) @@ expression E; @@ ( - to_intel_encoder(&E->base) + E | - to_intel_encoder(&E->base.base) + &E->base ) @@ identifier D, M; expression E; @@ D = enc_to_dig_port(&E->base) <... ( - D->base.M + E->M | - &D->base + E ) ...> @@ identifier D; expression E; type T; @@ - T D = enc_to_dig_port(E); ... when != D Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920185145.1912-10-ville.syrjala@linux.intel.com Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-10-01drm/i915: Use memmove() for punching the hole into infoframesVille Syrjälä
Replace the hand rolled memmove() with the real thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920185145.1912-9-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-10-01drm/i915: Combine multiple internal plists into the same i915_priolist bucketChris Wilson
As we are about to allow ourselves to slightly bump the user priority into a few different sublevels, packthose internal priority lists into the same i915_priolist to keep the rbtree compact and avoid having to allocate the default user priority even after the internal bumping. The downside to having an requests[] rather than a node per active list, is that we then have to walk over the empty higher priority lists. To compensate, we track the active buckets and use a small bitmap to skip over any inactive ones. v2: Use MASK of internal levels to simplify our usage. v3: Prevent overflow when SHIFT is zero. 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/20181001123204.23982-4-chris@chris-wilson.co.uk
2018-10-01drm/i915: Reserve some priority bits for internal useChris Wilson
In the next few patches, we will want to give a small priority boost to some requests/queues but not so much that we perturb the user controlled order. As such we will shift the user priority bits higher leaving ourselves a few low priority bits for our internal bumping. 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/20181001123204.23982-3-chris@chris-wilson.co.uk
2018-10-01drm/i915/selftests: Include arbitration points in preemption smoketestChris Wilson
Include a batch full of a page of arbitration points in order to provide a window for inject_preempt_context() in the preemption smoketests. 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/20181001123204.23982-2-chris@chris-wilson.co.uk
2018-10-01drm/i915/selftests: Split preemption smoke test into threadsChris Wilson
When submitting chains to each engine, we can do so (mostly) in parallel, so delegate submission to threads on a per-engine basis. 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/20181001123204.23982-1-chris@chris-wilson.co.uk
2018-09-28drm/i915/dp: optimize eDP 1.4+ link config fast and narrowJani Nikula
We've opted to use the maximum link rate and lane count for eDP panels, because typically the maximum supported configuration reported by the panel has matched the native resolution requirements of the panel, and optimizing the link has lead to problems. With eDP 1.4 rate select method and DSC features, this is decreasingly the case. There's a need to optimize the link parameters. Moreover, already eDP 1.3 states fast link with fewer lanes is preferred over the wide and slow. (Wide and slow should still be more reliable for longer cable lengths.) Additionally, there have been reports of panels failing on arbitrary link configurations, although arguably all configurations they claim to support should work. Optimize eDP 1.4+ link config fast and narrow. Side note: The implementation has a near duplicate of the link config function, with just the two inner for loops turned inside out. Perhaps there'd be a way to make this, say, more table driven to reduce the duplication, but seems like that would lead to duplication in the table generation. We'll also have to see how the link config optimization for DSC turns out. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: "Lee, Shawn C" <shawn.c.lee@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905095321.13843-1-jani.nikula@intel.com
2018-09-27drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ handlingDhinakaran Pandiyan
There are two copies of the same code called from long and short pulse handlers. v2: Rebase due to s/int status/enum drm_connector_status in intel_dp_detect() Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-6-dhinakaran.pandiyan@intel.com
2018-09-27drm/i915/dp: Kill intel_dp->detect_done flagDhinakaran Pandiyan
The intel_dp->detect_done flag is no more useful. Pull intel_dp_long_pulse() into the lone caller, Cc: Jani Nikula <jani.nikula@linux.intel.com> 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> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-5-dhinakaran.pandiyan@intel.com
2018-09-27drm/i915/dp: Do not grab crtc modeset lock in intel_dp_detect()Dhinakaran Pandiyan
A crtc modeset lock was added for link retraining but intel_dp_retrain_link() knows to take the necessary locks since commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") v2: Drop AUX power domain reference in the early return path Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-4-dhinakaran.pandiyan@intel.com
2018-09-27drm/i915/dp: Use a local variable for intel_encoder *Dhinakaran Pandiyan
We have two cases of intel_dp to intel_encoder conversions, use a local variable to store the conversion. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-3-dhinakaran.pandiyan@intel.com
2018-09-27drm/i915/dp: Restrict link retrain workaround to external monitorsDhinakaran Pandiyan
Commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")' applies a work around for sinks that don't signal link loss. The work around does not need to have to be that broad as the issue was seen with only one particular monitor; limit this only for external displays as eDP features like PSR turn off the link and the driver ends up retraining the link seeeing that link is not synchronized. Cc: Lyude Paul <lyude@redhat.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") 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/20180927205735.16651-2-dhinakaran.pandiyan@intel.com
2018-09-27drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse()Dhinakaran Pandiyan
Comment claims link needs to be retrained because the connected sink raised a long pulse to indicate link loss. If the sink did so, intel_dp_hotplug() would have handled link retraining. Looking at the logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-apply Perform link quality check, unconditionally during long pulse"")', the issue is that the sink does not trigger an interrupt. What we want is ->detect() from user space to check link status and retrain. Ville's review for the original patch also indicates the same root cause. So, rewrite the comment. v2: Patch split and rewrote comment. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") 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/20180927205735.16651-1-dhinakaran.pandiyan@intel.com
2018-09-27drm/i915/execlists: Avoid kicking priority on the current contextChris Wilson
If the request is currently on the HW (in port 0), then we do not need to kick the submission tasklet to evaluate whether we should be preempting itself in order to execute it again. In the case that was annoying me: execlists_schedule: rq(18:211173).prio=0 -> 2 need_preempt: last(18:211174).prio=0, queue.prio=2 We are bumping the priority of the first of a pair of requests running in the current context. Then when evaluating preempt, we would see that that our priority request is higher than the last executing request in ELSP0 and so trigger preemption, not realising that our intended request was already executing. v2: As we assume state of the execlists->port[] that is only valid while we hold the timeline lock we have to repeat some earlier tests that on the validity of the node. v3: Wrap guc submission under the timeline.lock as is now the way of all things. 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/20180925083205.2229-2-chris@chris-wilson.co.uk
2018-09-27drm/i915/csr: restructure CSR firmware definition macrosJani Nikula
Use uniform prefixes for firmware path, version and size. Unify alignments. Order macro groups as in the if ladder using them. Add platform specific max firmware size macros for all platforms for clarity in the if ladder. Place the max firmware size macros in the platform specific macro groups. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927075311.5076-1-jani.nikula@intel.com
2018-09-27drm/i915: Check for panel orientation quirks on eDP panelsHans de Goede
So far we have only been calling drm_connector_init_panel_orientation_property(), which checks for panel orientation quirks in the drm_panel_orientation_quirks.c file, for DSI panels as so far only devices with DSI panels have had panels which are not mounted up right. The new GPD win2 device uses a portrait screen in a landscape case, so now we've a device with an eDP panel which needs the panel-orientation property to let the fbcon code and userspace know that the image needs to be fixed-up. This commit makes intel_edp_init_connector() call drm_connector_init_panel_orientation_property() so that the property gets added. Reported-and-tested-by: russianneuromancer@ya.ru Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180909133457.10636-2-hdegoede@redhat.com
2018-09-27drm/i915: Remove i915.enable_ppgtt overrideChris Wilson
Now that we are confident in providing full-ppgtt where supported, remove the ability to override the context isolation. v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted. v3: s/USES/HAS/ to match usage and reject attempts to load the module on old GVT-g setups that do not provide support for full-ppgtt. v4: Insulate ABI ppGTT values from our internal enum (later plans involve moving ppGTT depth out of the enum, thus potentially breaking ABI unless we document the current values). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Zhi Wang <zhi.a.wang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926201222.5643-1-chris@chris-wilson.co.uk
2018-09-27drm/i915: Log HWS seqno consistentlyTvrtko Ursulin
We mix hexa- and decimal which is confusing when reading the logs. So make the single odd one out instance decimal for consistency. v2: * Do the intel_ringbuffer.c as well. (Chris Wilson) 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> Link: https://patchwork.freedesktop.org/patch/msgid/20180926145033.16318-1-tvrtko.ursulin@linux.intel.com
2018-09-27drm/i915: Trim partial view sg listsTvrtko Ursulin
Partial views are small but there can be many of them, and since the sg list space for them is allocated pessimistically, we can save some slab by trimming the unused tail entries. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180926080353.20867-1-tvrtko.ursulin@linux.intel.com
2018-09-27drm/i915/selftests: Smoketest preemptionChris Wilson
Very light stress test to bombard the submission backends with a large stream with requests of randomly assigned priorities. Preemption will be occasionally requested, but unlikely to ever succeed! (Although we may build a long queue of requests and so may trigger an attempt to inject a preempt context, as we emit no batch, the arbitration window is limited to between requests inside the ringbuffer. The likelihood of actually causing a preemption event is therefore very small. A later variant should try to improve the likelihood of preemption events!) v2: Include a second pattern with more frequent preemption Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180925083205.2229-1-chris@chris-wilson.co.uk
2018-09-27drm/i915/csr: bypass firmware request on i915.dmc_firmware_path=""Jani Nikula
With i915.dmc_firmware_path="" it's obvious the intention is to disable CSR firmware loading. Bypass the firmware request altogether in this case, with more obvious debug logging. v2: Use DRM_INFO for logging (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926133414.22073-3-jani.nikula@intel.com
2018-09-27drm/i915/csr: keep max firmware size together with firmare name and versionJani Nikula
Move max firmware size to the same if ladder with firmware name and required version. This allows us to detect the missing max size for a platform without actually loading the firmware, and makes the whole thing easier to maintain. We need to move the power get earlier to allow for early return in the missing platform case. While at it, extend the comment on why we return with the reference held on errors. We also need to move the module parameter override later to reuse the max firmware size, which is independent of the override. v2: Add comment on why we leak the wakeref on errors (Chris) v3: Rebase Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926133414.22073-2-jani.nikula@intel.com
2018-09-27drm/i915/csr: keep firmware name and required version togetherJani Nikula
Having two separate if ladders gets increasingly hard to maintain. Put them together. v2: Rebase Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926133414.22073-1-jani.nikula@intel.com
2018-09-26drm/i915: Remove duplicated definition of intel_update_rawclkJosé Roberto de Souza
A few line above we have another definition of intel_update_rawclk() keeping that one as the function is implemented in intel_cdclk.c. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-6-jose.souza@intel.com
2018-09-26drm/i915: Move IPC WA #1141 to init_ipc()José Roberto de Souza
symmetric_memory do not change after initialization so lets just set ipc_enabled once for this WA. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-5-jose.souza@intel.com
2018-09-26drm/i915: Move SKL IPC WA to HAS_IPC()José Roberto de Souza
SKL has IPC but it should not be set according to the WA, so lets just mark as it don't have it to simply the code and avoid unnecessary MMIO writes at every call to intel_enable_ipc(). Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-4-jose.souza@intel.com
2018-09-26drm/i915: Do not modifiy reserved bit in gens that do not have IPCJosé Roberto de Souza
IPC was only added in SKL+(actually we don't even enable for SKL due WA) so without this change, driver was writing to a reserved bit. Also removing the uncessary dev_priv->ipc_enabled = false; as now gens without IPC will not have IPC enabled. v2(Rodrigo): - moved the new handling of WA #0477 to the next patch Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-3-jose.souza@intel.com
2018-09-26drm/i915: Unset reset pch handshake when PCH is not present in one placeJosé Roberto de Souza
Right now RESET_PCH_HANDSHAKE_ENABLE is enabled all the times inside of intel_power_domains_init_hw() and if PCH is NOP it is unsed in i915_gem_init_hw(). So making skl_pch_reset_handshake() handle both cases and calling it for the missing gens in intel_power_domains_init_hw(). Ivybridge have a different register and bits but with the same objective so moving it too. v2(Rodrigo): - handling IVYBRIDGE case inside intel_pch_reset_handshake() v4(Rodrigo and Ville): - moving the enable/disable decision to callers Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-2-jose.souza@intel.com
2018-09-26drm/i915/runtime_pm: Share code to enable/disable PCH reset handshakeJosé Roberto de Souza
Instead of have the same code spread into 4 platforms lets share it. BXT do not have a PCH so here also handling this case by unseting RESET_PCH_HANDSHAKE_ENABLE. v2(Rodrigo): - renamed to intel_pch_reset_handshake() - added comment about why BXT need the bit to be unset v3(Rodrigo and Ville): - added bool have_pch to intel_pch_reset_handshake() - added back BXT comment Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-1-jose.souza@intel.com
2018-09-26drm/i915/icl: Define TA_TIMING_PARAM registersMadhav Chauhan
This patch defines DSI_TA_TIMING_PARAM and DPHY_TA_TIMING_PARAM registers used in dphy programming. v2: Changes (Jani N) - Define mask/shift for bitfields - Use bitfields name as per BSPEC - Define remaining bitfields Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1537095223-5184-8-git-send-email-madhav.chauhan@intel.com
2018-09-26drm/i915/icl: Define data/clock lanes dphy timing registersMadhav Chauhan
This patch defines DSI_CLK_TIMING_PARAM, DPHY_CLK_TIMING_PARAM, DSI_DATA_TIMING_PARAM, DPHY_DATA_TIMING_PARAM register used in dphy programming. v2: Define mask/shift for bitfields and keep names as per BSPEC (Jani N) Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1537095223-5184-6-git-send-email-madhav.chauhan@intel.com
2018-09-26drm/i915: Avoid compiler warning for maybe unused gu_misc_iirChris Wilson
/kisskb/src/drivers/gpu/drm/i915/i915_irq.c: warning: 'gu_misc_iir' may be used uninitialized in this function [-Wuninitialized]: => 3120:10 Silence the compiler warning by ensuring that the local variable is initialised and removing the guard that is confusing the older gcc. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: df0d28c185ad ("drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926104718.17462-1-chris@chris-wilson.co.uk
2018-09-26drm/i915: Convert to BITS_PER_TYPEChris Wilson
In commit 9144d75e22ca ("include/linux/bitops.h: introduce BITS_PER_TYPE"), we made BITS_PER_TYPE available to all and now we can use the macro to replace some open-coded computation of sizeof(T) * BITS_PER_BYTE. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926104707.17410-1-chris@chris-wilson.co.uk
2018-09-26Merge drm/drm-next into drm-intel-next-queuedJani Nikula
Catch up in general, and get DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT specifically. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2018-09-25drm/i915: Check fb stride against plane max strideVille Syrjälä
commit 4e0b83a567e2 ("drm/i915: Extract per-platform plane->check() functions") removed the plane max stride check for sprite planes. I was going to add it back when introducing GTT remapping for the display, but after further thought it seems better to re-introduce it separately. So let's add the max stride check back. And let's do it in a nicer form than what we had before and do it for all plane types (easy now that we have the ->max_stride() plane vfunc). Only sprite planes really need this for now since primary planes are capable of scanning out the current max fb size we allow, and cursors have more stringent stride checks elsewhere. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: 4e0b83a567e2 ("drm/i915: Extract per-platform plane->check() functions") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918140243.12207-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
generated by cgit (git 2.34.1) at 2025-06-10 14:56:14 +0000