- 24 May, 2019 2 commits
-
-
Dave Airlie authored
This reverts commit 55143dc2. This causes build breakags with some Kconfigs so revert for now. Fixes: 55143dc2 ("drm/amd/display: Don't load DMCU for Raven 1") Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2019-05-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 Signed-off-by:
-
- 23 May, 2019 3 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Fixes for 5.2: - Fix for DMCU firmware issues for stable - Add missing polaris10 pci id to kfd - Screen corruption fix on picasso - Fix for driver reload on vega10 - SR-IOV fixes - Locking fix in new SMU code - Compute profile switching fix for KFD Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
- sun4i fixes to hdmi phy as well as u16 overflow in dsi (left from -next-fixes) - gma500 fix to make lvds detection more reliable - select devfreq for panfrost since it can't probe without it Signed-off-by:
-
git://people.freedesktop.org/~thomash/linuxDave Airlie authored
A set of misc fixes for various issues that have surfaced recently. All Cc'd stable except the dma iterator fix which shouldn't really cause any real issues on older kernels. Signed-off-by:
-
- 22 May, 2019 1 commit
-
-
Ezequiel Garcia authored
Currently, there is some logic for the driver to work without devfreq. However, the driver actually fails to probe if !CONFIG_PM_DEVFREQ. Fix this by selecting devfreq, and drop the additional checks for devfreq. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190517150042.776-1-ezequiel@collabora.com
-
- 21 May, 2019 15 commits
-
-
https://github.com/intel/gvt-linuxJoonas Lahtinen authored
gvt-fixes-2019-05-21 - vGPU reset fix with sane init breadcrumb (Weinan) - Fix TRTT handling to use context state (Yan) - Fix one error return (Dan) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190521062408.GH12913@zhen-hp.sh.intel.com
-
Patrik Jakobsson authored
Some machines have an lvds child device in vbt even though a panel is not attached. To make detection more reliable we now also check the lvds config bits available in the vbt. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766 Cc: stable@vger.kernel.org Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416114607.1072-1-patrik.r.jakobsson@gmail.com
-
Murray McAllister authored
If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID of SVGA3D_INVALID_ID, and a shader type of SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot will be 4294967295, leading to an out-of-bounds read in vmw_binding_loc() when the offset is calculated. Cc: <stable@vger.kernel.org> Fixes: d80efd5c ("drm/vmwgfx: Initial DX support") Signed-off-by:
Murray McAllister <murray.mcallister@gmail.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Murray McAllister authored
If SVGA_3D_CMD_DX_DEFINE_RENDERTARGET_VIEW is called with a surface ID of SVGA3D_INVALID_ID, the srf struct will remain NULL after vmw_cmd_res_check(), leading to a null pointer dereference in vmw_view_add(). Cc: <stable@vger.kernel.org> Fixes: d80efd5c ("drm/vmwgfx: Initial DX support") Signed-off-by:
-
Thomas Hellstrom authored
Use struct sg_dma_page_iter in favour struct of sg_page_iter, which fairly recently was declared useless for obtaining dma addresses. With a struct sg_dma_page_iter we can't call sg_page_iter_page() so when the page is needed, use the same page lookup mechanism as for the non-sg dma modes instead of calling sg_dma_page_iter. Note, the fixes tag doesn't really point to a commit introducing a failure / regression, but rather to a commit that implemented a simple workaround for this problem. Cc: Jason Gunthorpe <jgg@mellanox.com> Fixes: d901b276 ("lib/scatterlist: Provide a DMA page iterator") Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com>
-
Thomas Hellstrom authored
In compat mode, we allowed host-backed user-space with guest-backed kernel / device. In this mode, set shader commands was broken since no relocations were emitted. Fix this. Cc: <stable@vger.kernel.org> Fixes: e8c66efb ("drm/vmwgfx: Make user resource lookups reference-free during validation") Signed-off-by:
Brian Paul <brianp@vmware.com>
-
Thomas Hellstrom authored
User-space handles equal to zero are interpreted as uninitialized or illegal by some drm systems (most notably kms). This means that a dumb buffer or surface with a zero user-space handle can never be used as a kms frame-buffer. Cc: <stable@vger.kernel.org> Fixes: c7eae626 ("drm/vmwgfx: Make the object handles idr-generated") Signed-off-by:
Deepak Rawat <drawat@vmware.com>
-
Thomas Hellstrom authored
This may confuse user-space clients like plymouth that opens a drm file descriptor as a result of a hotplug event and then generates a new event... Cc: <stable@vger.kernel.org> Fixes: 5ea17348 ("drm/vmwgfx: Send a hotplug event at master_set") Signed-off-by:
-
Dan Carpenter authored
"ret" is uninitialized on this path but it should be -EINVAL. Fixes: 930c8dfe ("drm/i915/gvt: Check if get_next_pt_type() always returns a valid value") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Yan Zhao authored
the vGPU write on TRTTE and 0x4dfc is now write to vreg first. their values all be restored hardware when context switching. Fixes: e39c5add ("drm/i915/gvt: vGPU MMIO virtualization") Acked-by:
Yan Zhao <yan.y.zhao@intel.com> Signed-off-by:
-
Yan Zhao authored
0x4dfc is in-context mmio for gen9+, but each vm have different settings need to add it to save-restore list along with other trtt registers Fixes: 17865713 ("drm/i915/gvt: vGPU context switch") Acked-by:
-
Yan Zhao authored
TRVATTL3PTRDW(0x4de0-0x4de4), TRNULLDETCT(0x4de8), TRINVTILEDETCT(0x4dec), TRTTE(0x4df0), TRVADR(0x4df4) are in-context mmios for gen9+ Fixes: 17865713 ("drm/i915/gvt: vGPU context switch") Acked-by:
-
Yan Zhao authored
for restore-inhibit context, hardware will not load in-context mmios (engine context part) to hardware, but hardware will save the mmio values in hardware back to context image. So, in order to save correct values of vGPU back to context image, values of vGPU mmios have to be loaded into hardware first for restore-inhibit context. In this patch, the mechanism is applied to all gen9 platform. The reason excluding gen8 platforms is only because of lacking of testing on those platforms. v3: for mocs registers, goto in-context mmios save-restore path for skl platform as well (weinan li) v2: update vreg when scanning indirect context for inhibit context for gen9 Cc: Weinan Li <weinan.z.li@intel.com> Acked-by:
Weinan Li <weinan.z.li@intel.com> Signed-off-by:
-
Weinan authored
"To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced past the start of this request." It means all the request which timeline's has_init_breadcrumb is true, then the emit_init_breadcrumb process must have before emitting the real commands, otherwise, the scheduler might get a wrong state of this request during reset. If the request is exactly the guilty one, the scheduler won't terminate it with the wrong state. To avoid this, do emit_init_breadcrumb for all the requests from gvt. v2: cc to stable kernel Fixes: 85474441 ("drm/i915: Identify active requests") Cc: stable@vger.kernel.org Acked-by:
-
Harish Kasiviswanathan authored
Fix compute profile switching on process termination. Add a dedicated reference counter to keep track of entry/exit to/from compute profile. This enables switching compute profiles for other reasons than process creation or termination. Signed-off-by:
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by:
Eric Huang <JinhuiEric.Huang@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
- 20 May, 2019 14 commits
-
-
Yintian Tao authored
PSP fw primary buffer is not used under SRIOV. Under SRIOV, VBIOS or hypervisor driver will load psp sos and psp sysdrv. Therefore, we don't need to allocate memory for it. v2: remove superfluous check for amdgpu_bo_free_kernel(). Signed-off-by:
Yintian Tao <yttao@amd.com> Signed-off-by:
Monk Liu <Monk.Liu@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Dan Carpenter authored
There is a typo so the code unlocks twice instead of taking the lock and then releasing it. Fixes: f14a323d ("drm/amd/powerplay: implement update enabled feature state to smc for smu11") Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Alex Deucher authored
For SR-IOV, vram_width can't be read from ATOM as RAVEN, and DF related registers is not readable, so hardcord is the only way to set the correct vram_width. Reviewed-by:
Trigger Huang <Trigger.Huang@amd.com> Signed-off-by:
-
Alex Deucher authored
Not necessary on soc15 and breaks driver reload on server cards. Acked-by:
Amber Lin <Amber.Lin@amd.com> Signed-off-by:
-
Flora Cui authored
otherwise screen corrupts during modprobe. Signed-off-by:
Flora Cui <flora.cui@amd.com> Reviewed-by:
Feifei Xu <Feifei.Xu@amd.com> Signed-off-by:
-
Kent Russell authored
This was added to amdgpu but was missed in amdkfd Signed-off-by:
Kent Russell <kent.russell@amd.com> Reviewed-by:
-
Harry Wentland authored
[WHY] Some early Raven boards had a bad SBIOS that doesn't play nicely with the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU load but that doesn't seem to be the case. We've still seen reports of users unable to boot their systems at all. [HOW] Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
Harry Wentland authored
[WHY] We only want to load DMCU FW on Picasso and Raven 2, not on Raven 1. Signed-off-by:
-
Chris Wilson authored
In commit b7404c7e ("drm/i915: Bump ready tasks ahead of busywaits"), I tried cutting a corner in order to not install a signal for each of our dependencies, and only listened to requests on which we were intending to busywait. The compromise that was made was that instead of then being able to promote the request with a full NOSEMAPHORE like its non-busywaiting brethren, as we had not ensured we had cleared the semaphore chain, we settled for only using the NEWCLIENT boost. With an over saturated system with multiple NEWCLIENTS in flight at any time, this was found to be an inadequate promotion and left us with a much poorer scheduling order than prior to using semaphores. The outcome of this patch, is that all requests have NOSEMAPHORE priority when they have no dependencies and are ready to run and not busywait, restoring the pre-semaphore ordering on saturated systems. We can demonstrate the effect of poor scheduling order by oversaturating the system using gem_wsim on a system with multiple vcs engines (i.e running the same workloads across more clients than required for peak throughput, e.g. media_load_balance_17i7.wsim -c4 -b context): x v5.1 (normalized) + tip * fix +------------------------------------------------------------------------+ | x | | x | | x | | x | | %x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %#x | | %#x | | %#x | | %#x | | %#x | | + %#xx | | + %#xx | | + %%#xx | | + %%#xx | | + %%#xx | | + %%#xx | | + %%##x | | +++ %%##x | | +++ %%##x | | +++ %%##x | | ++++ %%##x | | ++++ %%##x | | ++++ %%##xx | | ++++ %###xx | | ++++ %###xx | | ++++ %###xx | | ++++ %###xx | | ++++ + %#O#xx | | ++++ + %#O#xx | | ++++++ + %#O#xx | | ++++++++++ %OOOxxx| | ++++++++++ + %#OOO#xx| | + ++++++++++++ ++ +++++ + ++ @@OOOO#xx| | |A_| | ||__________M_______A____________________| | | |A_| | +------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 120 0.99456 1.00628 0.999985 1.0001545 0.0024387139 + 120 0.873021 1.00037 0.884134 0.90148752 0.039190862 Difference at 99.5% confidence -0.098667 +/- 0.0110762 -9.86517% +/- 1.10745% (Student's t, pooled s = 0.0277657) % 120 0.990207 1.00165 0.9970265 0.99699748 0.0021024 Difference at 99.5% confidence -0.003157 +/- 0.000908245 -0.315651% +/- 0.0908105% (Student's t, pooled s = 0.00227678) Fixes: b7404c7e ("drm/i915: Bump ready tasks ahead of busywaits") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Dmitry Ermilov <dmitry.ermilov@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190515130052.4475-2-chris@chris-wilson.co.uk (cherry picked from commit 17db337f) Signed-off-by:
-
Chris Wilson authored
Commit 1413b2bc ("drm/i915: Trim NEWCLIENT boosting") had the intended consequence of not allowing a sequence of work that merely crossed into a new engine the privilege to be promoted to NEWCLIENT status. It also had the unintended consequence of actually making NEWCLIENT effective on heavily oversubscribed transcode machines and impacting upon their throughput. If we consider a client packet composed of (rcsA, rcsB, vcs) and 30 of those clients, using the NEWCLIENT boost that will be scheduled as rcsA x 30, (rcsB, vcs) x 30 where as before it would have been (rcsA, rcsB, vcs) x 30 That is with NEWCLIENT only boosting the first request of each client, we would execute all rcsA requests prior to running on the vcs engines; acruing a lot of dead time as compared to the previous case where the vcs engine would be started in parallel to processing the second client. The previous patch has the effect of delaying submission until it is required by a third party (either the user with an explicit wait, or by another client/engine). We reduce the NEWCLIENT bump to a mere WAIT, which has the effect of removing its preemptive grant and reducing it to the same level as any other user interaction -- that it will not be promoted above the interengine dependencies, and so preventing NEWCLIENTS from starving other engines. This a large nerf to the rrul properties of the current NEWCLIENT, but it still does give prioritised submission to new requests from light workloads. References: b16c7651 ("drm/i915: Priority boost for new clients") Fixes: 1413b2bc ("drm/i915: Trim NEWCLIENT boosting") # customer impact Signed-off-by:
-
Chris Wilson authored
The handling of the no-preemption priority level imposes the restriction that we need to maintain the implied ordering even though preemption is disabled. Otherwise we may end up with an AB-BA deadlock across multiple engine due to a real preemption event reordering the no-preemption WAITs. To resolve this issue we currently promote all requests to WAIT on unsubmission, however this interferes with the timeslicing requirement that we do not apply any implicit promotion that will defeat the round-robin timeslice list. (If we automatically promote the active request it will go back to the head of the queue and not the tail!) So we need implicit promotion to prevent reordering around semaphores where we are not allowed to preempt, and we must avoid implicit promotion on unsubmission. So instead of at unsubmit, if we apply that implicit promotion on adding the dependency, we avoid the semaphore deadlock and we also reduce the gains made by the promotion for user space waiting. Furthermore, by keeping the earlier dependencies at a higher level, we reduce the search space for timeslicing without altering runtime scheduling too badly (no dependencies at all will be assigned a higher priority for rrul). v2: Limit the bump to external edges (as originally intended) i.e. between contexts and out to the user. Testcase: igt/gem_concurrent_blit Signed-off-by:
-
Chris Wilson authored
To simplify the next patch, update bump_priority and schedule to accept the internal i915_sched_ndoe directly and not expect a request pointer. add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7) Function old new delta i915_schedule_bump_priority 109 113 +4 i915_schedule 50 54 +4 __i915_schedule 922 907 -15 v2: Adopt node for the old rq local, since it no longer is a request but the origin node. Signed-off-by:
-
Chris Wilson authored
To avoid pulling in a forward declaration in the next patch, move the i915_sched_node handling to after the main dfs of the scheduler. Signed-off-by:
-
Sean Paul authored
Picking up 3 sun4i patches that missed the last drm-misc-next-fixes pull request for 5.2 Signed-off-by:Sean Paul <seanpaul@chromium.org>
-
- 19 May, 2019 5 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifsLinus Torvalds authored
Pull UBIFS fixes from Richard Weinberger: - build errors wrt xattrs - mismerge which lead to a wrong Kconfig ifdef - missing endianness conversion * tag 'upstream-5.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs: ubifs: Convert xattr inum to host order ubifs: Use correct config name for encryption ubifs: Fix build error without CONFIG_UBIFS_FS_XATTR
-
Linus Torvalds authored
Merge yet more updates from Andrew Morton: "A few final bits: - large changes to vmalloc, yielding large performance benefits - tweak the console-flush-on-panic code - a few fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: panic: add an option to replay all the printk message in buffer initramfs: don't free a non-existent initrd fs/writeback.c: use rcu_barrier() to wait for inflight wb switches going into workqueue when umount mm/compaction.c: correct zone boundary handling when isolating pages from a pageblock mm/vmap: add DEBUG_AUGMENT_LOWEST_MATCH_CHECK macro mm/vmap: add DEBUG_AUGMENT_PROPAGATE_CHECK macro mm/vmalloc.c: keep track of free blocks for vmap allocation
-
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuildLinus Torvalds authored
Pull more Kbuild updates from Masahiro Yamada: - remove unneeded use of cc-option, cc-disable-warning, cc-ldoption - exclude tracked files from .gitignore - re-enable -Wint-in-bool-context warning - refactor samples/Makefile - stop building immediately if syncconfig fails - do not sprinkle error messages when $(CC) does not exist - move arch/alpha/defconfig to the configs subdirectory - remove crappy header search path manipulation - add comment lines to .config to clarify the end of menu blocks - check uniqueness of module names (adding new warnings intentionally) * tag 'kbuild-v5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (24 commits) kconfig: use 'else ifneq' for Makefile to improve readability kbuild: check uniqueness of module names kconfig: Terminate menu blocks with a comment in the generated config kbuild: add LICENSES to KBUILD_ALLDIRS kbuild: remove 'addtree' and 'flags' magic for header search paths treewide: prefix header search paths with $(srctree)/ media: prefix header search paths with $(srctree)/ media: remove unneeded header search paths alpha: move arch/alpha/defconfig to arch/alpha/configs/defconfig kbuild: terminate Kconfig when $(CC) or $(LD) is missing kbuild: turn auto.conf.cmd into a mandatory include file .gitignore: exclude .get_maintainer.ignore and .gitattributes kbuild: add all Clang-specific flags unconditionally kbuild: Don't try to add '-fcatch-undefined-behavior' flag kbuild: add some extra warning flags unconditionally kbuild: add -Wvla flag unconditionally arch: remove dangling asm-generic wrappers samples: guard sub-directories with CONFIG options kbuild: re-enable int-in-bool-context warning MAINTAINERS: kbuild: Add pattern for scripts/*vmlinux* ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c updates from Wolfram Sang: "Some I2C core API additions which are kind of simple but enhance error checking for users a lot, especially by returning errno now. There are wrappers to still support the old API but it will be removed once all users are converted" * 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: core: add device-managed version of i2c_new_dummy i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy
-
