- 30 1月, 2018 3 次提交
-
-
由 Imre Deak 提交于
While running the kms_plane clipping test I noticed a similar problem to the one described in Display WA #1175. In this case, similarly for planes other than the cursor, with 1 or 3 pixels visible from the left edge of the screen to the end of the plane and an odd plane X offset used for clipping causes the same kind of underflow and display corruption as described for WA #1175. Fix this in a similar way as that WA rejecting planes ending <4 pixels from the left screen edge. v2: - Rebase on v2 of patch 1/1. Testcase: igt/kms_plane/plane-clipping-pipe-*-planes Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180116112415.22060-2-imre.deak@intel.com
-
由 Imre Deak 提交于
As described in the WA on GLK and CNL planes on the right edge of the screen that have less than 4 pixels visible from the beginning of the plane to the edge of the screen can cause FIFO underflow and display corruption. On GLK/CNL I could trigger the problem only if the plane was at the same time also aligned to the top edge of the screen (after clipping) and there were exactly 2 pixels visible from the start of the plane to the right edge of the screen (so couldn't trigger it with 1 or 3 pixels visible). Nevertheless, to be sure, I also applied the WA for these cases. I also couldn't see any problem with the cursor plane and later Art confirmed that it's not affected, so the WA is applied only for the other plane types. v2: - Use -ERANGE instead of -EINVAL. (Chris) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180116112415.22060-1-imre.deak@intel.com
-
由 Rodrigo Vivi 提交于
If the table result is out of bounds on the array map there is something really wrong with VBT pin so we don't return that vbt_pin, but only return 0 instead. This basically reverts commit 'a8e6f388 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.")' Also this properly fixes commit 9c3b2689 ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") v2: Do in a way that we don't break other platforms. (Jani) v3: Keep debug message (Jani) v4: Don't mess with 0 mapping was noticed by Jani and addressed with a simple solution suggested by Lucas that makes this even simpler. Fixes: a8e6f388 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") Fixes: 9c3b2689 ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Kai Heng Feng <kai.heng.feng@canonical.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Tested-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125222524.22059-1-rodrigo.vivi@intel.com
-
- 29 1月, 2018 3 次提交
-
-
由 Chris Wilson 提交于
Assert that we do not try to unsubmit a completed request, as should we try to resubmit it later, the ring is already past the request's breadcrumb and the breadcrumb will not be updated. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180129094912.14428-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
-
由 Chris Wilson 提交于
Older gcc is complaining it can't follow the guards and thinks that addr may be used uninitialised In the process, we can simplify down to one loop, add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-131 (-131) Function old new delta setup_scratch_page 545 414 -131 Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org> 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/20180129102840.19901-1-chris@chris-wilson.co.uk
-
由 Lionel Landwerlin 提交于
This reverts commit 5b54eddd. Conflicts: drivers/gpu/drm/i915/i915_pci.c Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Fixes: 5b54eddd ("drm/i915: mark all device info struct with __initconst") Link: https://patchwork.freedesktop.org/patch/msgid/20180129083346.29173-1-lionel.g.landwerlin@intel.com
-
- 26 1月, 2018 2 次提交
-
-
由 Chris Wilson 提交于
Remove the WARN_ON(ce->state) inside the static function only called when ce->state == NULL and downgrade the w/a batch setup warning into a developer only mode (GEM_WARN_ON). v2: Move the deferred alloc guard into the callee, eliminating the need for the WARN_ON: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1) Function old new delta execlists_context_pin 1819 1818 -1 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/20180126121846.12007-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
CTX_CONTEXT_CONTROL (CTX_SR_CTL) operates as a masked register and so will only apply the bits that are selected by the upper half. In the case of selectively enabling sr inhibit, this may mean the context keeps the current setting (so forgetting to save the context later, eventually leading to a very upset GPU!). Fixes: 517aaffe ("drm/i915/execlists: Inhibit context save/restore for the fake preempt context") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125112443.12745-1-chris@chris-wilson.co.ukReviewed-by: NMichel Thierry <michel.thierry@intel.com>
-
- 25 1月, 2018 10 次提交
-
-
由 Christian König 提交于
It should initialize before the drivers using it. Signed-off-by: NChristian König <christian.koenig@amd.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104736Reviewed-by: NMike Lothian <mike@fireburn.co.uk> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Harry Wentland 提交于
I assumed wrongfully that all relevant functions should be implemented. Apparently this isn't the case. Demote the print to debug level for now. Signed-off-by: NHarry Wentland <harry.wentland@amd.com> Reviewed-by: NTony Cheng <Tony.Cheng@amd.com> Acked-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Sagar Arun Kamble 提交于
Use consistent multi-line comment style as per guideline. v2: Reverted comments prefix update to kernel-doc comment. (Chris) Suggested-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/1516808821-3638-5-git-send-email-sagar.a.kamble@intel.com
-
由 Sagar Arun Kamble 提交于
i915_guc_log_control is GuC interface and GuC APIs that are not user facing should be named with "intel_guc" prefix hence we change name to intel_guc_log_control. Also changed the parameter to intel_guc struct. v2: Move log vma check to intel_guc_log_control (Michal) Return -ENODEV when log isn't initialized. (Chris) Suggested-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-4-git-send-email-sagar.a.kamble@intel.com
-
由 Sagar Arun Kamble 提交于
This patch fixes lockdep issue due to circular locking dependency of struct_mutex, i_mutex_key, mmap_sem, relay_channels_mutex. For GuC log relay channel we create debugfs file that requires i_mutex_key lock and we are doing that under struct_mutex. So we introduced newer dependency as: &dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem However, there is dependency from mmap_sem to struct_mutex. Hence we separate the relay create/destroy operation from under struct_mutex. Also added runtime check of relay buffer status. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> ====================================================== WARNING: possible circular locking dependency detected 4.15.0-rc6-CI-Patchwork_7614+ #1 Not tainted ------------------------------------------------------ debugfs_test/1388 is trying to acquire lock: (&dev->struct_mutex){+.+.}, at: [<00000000d5e1d915>] i915_mutex_lock_interruptible+0x47/0x130 [i915] but task is already holding lock: (&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_sem){++++}: _copy_to_user+0x1e/0x70 filldir+0x8c/0xf0 dcache_readdir+0xeb/0x160 iterate_dir+0xdc/0x140 SyS_getdents+0xa0/0x130 entry_SYSCALL_64_fastpath+0x1c/0x89 -> #2 (&sb->s_type->i_mutex_key#3){++++}: start_creating+0x59/0x110 __debugfs_create_file+0x2e/0xe0 relay_create_buf_file+0x62/0x80 relay_late_setup_files+0x84/0x250 guc_log_late_setup+0x4f/0x110 [i915] i915_guc_log_register+0x32/0x40 [i915] i915_driver_load+0x7b6/0x1720 [i915] i915_pci_probe+0x2e/0x90 [i915] pci_device_probe+0x9c/0x120 driver_probe_device+0x2a3/0x480 __driver_attach+0xd9/0xe0 bus_for_each_dev+0x57/0x90 bus_add_driver+0x168/0x260 driver_register+0x52/0xc0 do_one_initcall+0x39/0x150 do_init_module+0x56/0x1ef load_module+0x231c/0x2d70 SyS_finit_module+0xa5/0xe0 entry_SYSCALL_64_fastpath+0x1c/0x89 -> #1 (relay_channels_mutex){+.+.}: relay_open+0x12c/0x2b0 intel_guc_log_runtime_create+0xab/0x230 [i915] intel_guc_init+0x81/0x120 [i915] intel_uc_init+0x29/0xa0 [i915] i915_gem_init+0x182/0x530 [i915] i915_driver_load+0xaa9/0x1720 [i915] i915_pci_probe+0x2e/0x90 [i915] pci_device_probe+0x9c/0x120 driver_probe_device+0x2a3/0x480 __driver_attach+0xd9/0xe0 bus_for_each_dev+0x57/0x90 bus_add_driver+0x168/0x260 driver_register+0x52/0xc0 do_one_initcall+0x39/0x150 do_init_module+0x56/0x1ef load_module+0x231c/0x2d70 SyS_finit_module+0xa5/0xe0 entry_SYSCALL_64_fastpath+0x1c/0x89 -> #0 (&dev->struct_mutex){+.+.}: __mutex_lock+0x81/0x9b0 i915_mutex_lock_interruptible+0x47/0x130 [i915] i915_gem_fault+0x201/0x790 [i915] __do_fault+0x15/0x70 __handle_mm_fault+0x677/0xdc0 handle_mm_fault+0x14f/0x2f0 __do_page_fault+0x2d1/0x560 page_fault+0x4c/0x60 other info that might help us debug this: Chain exists of: &dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#3); lock(&mm->mmap_sem); lock(&dev->struct_mutex); *** DEADLOCK *** 1 lock held by debugfs_test/1388: #0: (&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560 stack backtrace: CPU: 2 PID: 1388 Comm: debugfs_test Not tainted 4.15.0-rc6-CI-Patchwork_7614+ #1 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016 Call Trace: dump_stack+0x5f/0x86 print_circular_bug.isra.18+0x1d0/0x2c0 __lock_acquire+0x14ae/0x1b60 ? lock_acquire+0xaf/0x200 lock_acquire+0xaf/0x200 ? i915_mutex_lock_interruptible+0x47/0x130 [i915] __mutex_lock+0x81/0x9b0 ? i915_mutex_lock_interruptible+0x47/0x130 [i915] ? i915_mutex_lock_interruptible+0x47/0x130 [i915] ? i915_mutex_lock_interruptible+0x47/0x130 [i915] i915_mutex_lock_interruptible+0x47/0x130 [i915] ? __pm_runtime_resume+0x4f/0x80 i915_gem_fault+0x201/0x790 [i915] __do_fault+0x15/0x70 ? _raw_spin_unlock+0x29/0x40 __handle_mm_fault+0x677/0xdc0 handle_mm_fault+0x14f/0x2f0 __do_page_fault+0x2d1/0x560 ? page_fault+0x36/0x60 page_fault+0x4c/0x60 v2: Added lock protection to guc->log.runtime.relay_chan (Chris) Fixed locking inside guc_flush_logs uncovered by new lockdep. v3: Locking guc_read_update_log_buffer entirely with relay_lock. (Chris) Prepared intel_guc_init_early. Moved relay_lock inside relay_create relay_destroy, relay_file_create, guc_read_update_log_buffer. (Michal) Removed struct_mutex lock around guc_log_flush and removed usage of guc_log_has_relay() from runtime_create path as it needs struct_mutex lock. v4: Handle NULL relay sub buffer pointer earlier in read_update_log_buffer (Chris). Fixed comment suffix **/. (Michal) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693 Testcase: igt/debugfs_test/read_all_entries # with enable_guc=1 and guc_log_level=1 Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-3-git-send-email-sagar.a.kamble@intel.com
-
由 Sagar Arun Kamble 提交于
GuC log streaming needs interrupts enabled prior to GuC resume but runtime pm interrupt setup was happening post GuC resume. Fix it. While at it, fix the unwinding of steps in the runtime suspend path. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Marta Lofstedt <marta.lofstedt@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/1516808821-3638-2-git-send-email-sagar.a.kamble@intel.com
-
由 Sagar Arun Kamble 提交于
Disabling GuC interrupts involves access to GuC IRQ control registers hence ensure device is RPM awake. v1-v2: old changelog 1: Add comment about need to synchronize flush work and log runtime destroy 2: Moved patch earlier in the series and removed comment about future work. (Tvrtko) v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris) Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@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/1516808821-3638-1-git-send-email-sagar.a.kamble@intel.com
-
由 Ville Syrjälä 提交于
Let's document why we claim hsub==8,vsub==16 for CCS. v2: Replace my explanation with Jason's Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119144152.17224-1-ville.syrjala@linux.intel.comReviewed-by: NJason Ekstrand <jason@jlekstrand.net>
-
由 Ville Syrjälä 提交于
Apparently SKL/KBL/CFL need some manual help to get the programmed HDMI vswing to stick. Implement the relevant workaround (display w/a #1143). Note that the relevant chicken bits live in a transcoder register even though the bits affect a specific DDI port rather than a specific transcoder. Hence we must pick the correct transcoder register instance based on the port rather than based on the cpu_transcoder. Also note that for completeness I included support for DDI A/E in the code even though we never have HDMI on those ports. v2: CFL needs the w/a as well (Rodrigo and Art) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122174131.28046-1-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Ville Syrjälä 提交于
Replace the ad-hoc plane indexing scheme used by the frontbuffer tracking with enum plane_id. The old video overlay not being part of the plane_id namespace will just be given the high bit. v2: Drop the unintended whitespace change (Chris) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123183343.9181-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 24 1月, 2018 8 次提交
-
-
由 Chris Wilson 提交于
When we finally decide the gpu is idle, that is a good time to shrink our kmem_caches. v3: Defer until an rcu grace period after we idle. v4: Think about epoch wraparound and how likely that is. v5: Use I915_EPOCH_INVALID magic. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180124113608.14909-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
By counting the number of times we have woken up, we have a very simple means of defining an epoch, which will come in handy if we want to perform deferred tasks at the end of an epoch (i.e. while we are going to sleep) without imposing on the next activity cycle. v2: No reason to specify precise number of bits here. v3: Take Tvrtko's advice and reserve 0 as an invalid epoch. 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/20180124113608.14909-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
We only use the preempt context to inject an idle point into execlists. We never need to reference its logical state, so tell the GPU never to load it or save it. v2: BIT(2) for save-inhibit. N.B. Daniele mentioned this bit mbz for ICL, and has been moved into the submission process rather than the context image. Suggested-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NMichel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123210412.17653-1-chris@chris-wilson.co.uk
-
由 Michel Thierry 提交于
Newer platforms may have subtle offset changes, which will increase the number of defines, so it is probably better to start moving them to its own header file. Also move the macros used while setting the reg state. v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and intel_guc_reg.h (Chris) v3: License notice shenanigans. v4: Documentation/process/coding-style.rst is always right (Chris) v5: Rebase. Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180124004349.22126-2-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Michel Thierry 提交于
The macros we use to init the reg_state had the following issues reported by checkpatch --strict. Macro argument reuse 'reg_state' - possible side-effects Macro argument reuse 'pos' - possible side-effects Macro argument reuse 'ppgtt' - possible side-effects spaces preferred around that '+' (ctx:VxV) So fix these issues before they are moved to a new header file. Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180124004349.22126-1-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Tvrtko Ursulin 提交于
We need to generate the event config value using the uAPI class and not the driver internal one. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 109ec558 ("drm/i915/pmu: Only enumerate available counters in sysfs") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180123134558.3222-1-tvrtko.ursulin@linux.intel.com
-
由 Rodrigo Vivi 提交于
Current code always select _CNL_AUX_ANAOVRD1_B register regardless the pw in use. CNL_DISP_PW_AUX_B = 9 CNL_DISP_PW_AUX_C = 10 CNL_DISP_PW_AUX_D = 11 And for pick we want B = 0 C = 1 D = 2 Fixes: ddd39e4b ("drm/i915/cnl: apply Display WA #1178 to fix type C dongles") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: NLucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123215245.24026-1-rodrigo.vivi@intel.com
-
由 Rodrigo Vivi 提交于
Let's ignore VBT request if the pin is clearly wrong. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139 Cc: Kai Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123174050.4261-1-rodrigo.vivi@intel.comReviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
-
- 23 1月, 2018 7 次提交
-
-
由 Alex Deucher 提交于
We only support vga_switcheroo and runtime pm on PX/HG systems so forcing runpm to 1 doesn't do anything useful anyway. Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so that the cleanup path is correct as well. This mirrors what radeon does as well. v2: rework the patch originally sent by Lukas (Alex) Acked-by: NLukas Wunner <lukas@wunner.de> Reported-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> (v1) Cc: stable@vger.kernel.org
-
由 James Zhu 提交于
Add Polaris version check if firmware support UVD encode Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NJames Zhu <James.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Andrey Grodzovsky 提交于
Otherwise it keeps rejecting the reset. Signed-off-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Chris Wilson 提交于
Now that we can read the CSB from the HWSP, we may avoid having to perform mmio reads entirely and so forgo the rigmarole of the forcewake dance. v2: Include forcewake hint for GEM_TRACE readback of mmio. If we don't hold fw ourselves, the reads may return garbage. 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/20180122100714.15137-1-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
On gen9+, after an idle period the HW will disable the entire power well to conserve power (by preventing current leakage). It takes around a 100 microseconds to bring the power well back online afterwards. With the current hysteresis value of 25us (really 25 * 1280ns), we do not have sufficient time to respond to an interrupt and schedule the next execution before the HW powers itself down. (At present, we prevent this by grabbing the forcewake for prolonged periods of time, but that overkill fixed in the next patch.) The minimum we want to set the power gating hysteresis to is the length of time it takes us to service the GPU, which across a broad spectrum of machines is about 250us. (Note this also brings guc latency into the same ballpark as execlists.) v2: Include some notes on where I plucked the numbers from. Testcase: igt/gem_exec_nop/sequential Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122135541.32222-1-chris@chris-wilson.co.uk
-
由 Tvrtko Ursulin 提交于
We fail engine initialization if the scratch VMA cannot be created so there is no point in error handle it later. If the initialization ordering gets messed up, we can explode during development just as well. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMichel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119100005.9072-2-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
Render engine constructor helpers must only be called from the render engine constructors, but there is no need to burden the production binaries with warnings which can only be triggered during development. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMichel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119100005.9072-1-tvrtko.ursulin@linux.intel.com
-
- 22 1月, 2018 2 次提交
-
-
由 Manasi Navare 提交于
In case of eDP because the panel has a fixed mode, the link rate and lane count at which it is trained corresponds to the link BW required to support the native resolution of the panel. In case of panles with lower resolutions where fewer lanes are hooked up internally, that number is reflected in the MAX_LANE_COUNT DPCD register of the panel. So it is pointless to fallback to lower link rate/lane count in case of link training failure on eDP connector since the lower link BW will not support the native resolution of the panel and we cannot prune the preferred mode on the eDP connector. In case of Link training failure on the eDP panel, something is wrong in the HW internally and hence driver errors out with a loud and clear DRM_ERROR message. v2: * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala) Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NManasi Navare <manasi.d.navare@intel.com> Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103369Signed-off-by: NImre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1507835618-23051-1-git-send-email-manasi.d.navare@intel.com
-
由 Chris Wilson 提交于
As we attempt to allocate pages for use in a new WC stash, direct reclaim may run underneath us and fill up the WC stash. We have to be careful then not to overflow the pvec. Fixes: 66df1014 ("drm/i915: Keep a small stash of preallocated WC pages") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103109Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180121173143.17090-1-chris@chris-wilson.co.uk
-
- 20 1月, 2018 5 次提交
-
-
由 Dhinakaran Pandiyan 提交于
Avoids some typo pitfalls. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171220201021.17619-1-dhinakaran.pandiyan@intel.com
-
由 Huang Rui 提交于
MMHUB power gating still has issue, and doesn't work on raven at current. So disable it for the moment. Signed-off-by: NHuang Rui <ray.huang@amd.com> Acked-by: NHawking Zhang <Hawking.Zhang@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Chris Wilson 提交于
If we fail to allocate a new request, make sure we recover the pages that are in the process of being freed by inserting an RCU barrier. v2: Comment before the shrink and barrier in the error path. 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/20180119144657.22606-1-chris@chris-wilson.co.uk
-
由 Michal Wajdeczko 提交于
It looks that GuC log functionality is not fully functional yet and causes issues when enabled by auto(-1) modparam on debug builds. For example, but not limited to: [ 30.062893] ====================================================== [ 30.062894] WARNING: possible circular locking dependency detected [ 30.062895] 4.15.0-rc8-CI-CI_DRM_3648+ #1 Tainted: G U [ 30.062896] ------------------------------------------------------ [ 30.062897] debugfs_test/1268 is trying to acquire lock: [ 30.062898] (&dev->struct_mutex){+.+.}, at: [<00000000e4213449>] i915_mutex_lock_interruptible+0x47/0x130 [i915] [ 30.062921] but task is already holding lock: [ 30.062921] (&mm->mmap_sem){++++}, at: [<00000000dd7adc93>] __do_page_fault+0x106/0x560 [ 30.062924] which lock already depends on the new lock. References: 0ed87953 ("drm/i915/guc: Redefine guc_log_level modparam values") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104694 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119124926.29844-1-michal.wajdeczko@intel.comReviewed-by: NMichal Winiarski <michal.winiarski@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Tvrtko Ursulin 提交于
Gen11 removes the Resource Streamer, which frees up a big chunk of the context image. BSpec indicates 12544 DWORDs (13 pages), plus one page for PPHWSP. Please notice that, when looking at the BSpec context image table, the right filter has to be applied as some rows are excluded for specific GENs. Also, some rows apply per-subslice (for the calculation above, we have supposed I915_MAX_SUBSLICES = 8). v2: Rebase. v3: Use the right size as per the BSpec. v4: - Rebased on top of the default context size (Rodrigo) - Clarify in the commit message where the subslice calculation comes from. v5: s/12538/12544/ (Daniele) BSpec: 18907 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ben Widawsky <benjamin.widawsky@intel.com> (older version) Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NOscar Mateo <oscar.mateo@intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515711307-28979-2-git-send-email-oscar.mateo@intel.com
-