- 13 May, 2019 1 commit
-
-
Tomeu Vizoso authored
Dan Carpenter's static analysis tool reported: drivers/gpu/drm/panfrost/panfrost_drv.c:222 panfrost_ioctl_submit() error: we previously assumed 'sync_out' could be null (see line 216) Indeed, sync_out could be NULL if userspace doesn't send a sync object ID for the out fence. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lists.freedesktop.org/archives/dri-devel/2019-May/217014.htmlReviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190509082151.8823-1-tomeu.vizoso@collabora.com
-
- 09 May, 2019 2 commits
-
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2019-05-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-next - A handful of fixes from -next that just missed feature freeze - More panfrost fixes that went directly in -misc-next-fixes (various) - Fix searchpaths during build (Masahiro) - msm patch to fix the driver for chips without zap shader (Rob) - Fix freeing imported buffers in drm_gem_cma_free_object() (Noralf) Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Rob Clark <robdclark@chromium.org> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190508205153.GA91135@art_vandelay
-
git://linux-arm.org/linux-ldDave Airlie authored
This is the 2nd pull request for the malidp-next. The new patches add additional support for Arm Mali D71 so that it can now be enabled correctly and brought up on any SoC that contains the IP. From now on we will start focusing on adding writeback, scaling and other useful features to bring the driver to the same level of maturity as mali-dp. Signed-off-by:
-
- 08 May, 2019 2 commits
-
-
Rob Clark authored
Depending on platform firmware, a zap shader may not be required to take the GPU out of secure mode on boot, in which case we can just write RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed clearing 'ret' resulting that hw_init() returned an error on these devices. Fixes: abccb9fe ("drm/msm/a6xx: Add zap shader load") Acked-by:
Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by:
Sean Paul <sean@poorly.run> Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190508130726.27557-1-robdclark@gmail.com
-
Noralf Trønnes authored
The logic for freeing an imported buffer with a virtual address is broken. It will free the buffer instead of unmapping the dma buf. Fix by reversing the if ladder and first check if the buffer is imported. Fixes: b9068cde ("drm/cma-helper: Add DRM_GEM_CMA_VMAP_DRIVER_OPS") Cc: stable@vger.kernel.org Reported-by:
"Li, Tingqian" <tingqian.li@intel.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426124753.53722-1-noralf@tronnes.org
-
- 07 May, 2019 6 commits
-
-
Mario Kleiner authored
As discussed with Nicholas and Daniel Vetter (patchwork link to discussion below), the VRR timestamping behaviour produced utterly useless and bogus vblank/pageflip timestamps. We have found a way to fix this and provide sane behaviour. As of Linux 5.2, the amdgpu driver will be able to provide exactly the same vblank / pageflip timestamp semantic in variable refresh rate mode as in standard fixed refresh rate mode. This is achieved by deferring core vblank handling (drm_crtc_handle_vblank()) until the end of front porch, and also defer the sending of pageflip completion events until end of front porch, when we can safely compute correct pageflip/vblank timestamps. The same approach will be possible for other VRR capable kms drivers, so we can actually have sane and useful timestamps in VRR mode. This patch removes the section of the docs that describes the broken timestamp behaviour present in Linux 5.0/5.1. Fixes: ab7a664f ("drm: Document variable refresh properties") Link: https://patchwork.freedesktop.org/patch/285333/Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190418060157.18968-1-mario.kleiner.de@gmail.com Cc: stable@vger.kernel.org
-
Fix the kbuild test rebot reported warnings: - symbol was not declared. Should it be static? - missing braces around initializer Depends on: - https://patchwork.freedesktop.org/series/58976/Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
james qian wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com>
-
Fixed the warnings: Function parameter or member 'xxx' not described when make htmldocs This patch depends on: - https://patchwork.freedesktop.org/series/54448/ - https://patchwork.freedesktop.org/series/54449/ - https://patchwork.freedesktop.org/series/54450/ v2: Rebase and add reporter Reported-by:
-
CHIP set bus_width according to the HW configuration, and CORE will use it as buffer alignment. v2: Rebase Signed-off-by:
-
Add two sysfs node: core_id, config_id, user can read them to fetch the HW product information. Also, use memset to initialize config_id, rather than quirky C syntax. Courtesy of Nathan Chancellor <natechancellor@gmail.com>. Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> [Merged Nathan's patch that uses memset to initialize config_id into original patch as the fixes tag changed due to rebase, reworded the commit to reference the merged patch] Signed-off-by:
-
Andres Rodriguez authored
Add vendor/product pairs for the Valve Index HMDs. Signed-off-by:
Andres Rodriguez <andresx7@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: <stable@vger.kernel.org> # v4.15 Signed-off-by:
-
- 06 May, 2019 1 commit
-
-
https://git.pengutronix.de/git/lst/linuxDave Airlie authored
things are still slow in etnaviv land, so we don't have anything major to destage. Just a couple of non-critical fixes that I want to land in 5.2. Signed-off-by:
-
- 03 May, 2019 8 commits
-
-
Robin Murphy authored
Re-reading the feature registers for the sake of displaying the raw values seems pointless, and in fact showing the copies that we've already read and stored is arguably more useful in terms of giving exposure to any potential bugs in that part of the process. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Robin Murphy authored
Probe deferral is far from "fatal". Signed-off-by:
-
Robin Murphy authored
Make sure to disable runtime PM again if probe fails after we've enabled it. Otherwise, any subsequent attempt to re-probe starts triggering "Unbalanced pm_runtime_enable!" assertions from the driver core. Signed-off-by:
-
Robin Murphy authored
The DMA masks need to be set correctly before any DMA API activity kicks off, and the current point in panfrost_probe() is way too late in that regard. since panfrost_mmu_init() has already set up a live address space and DMA-mapped MMU pagetables. We can't set masks until we've queried the appropriate value from MMU_FEATURES, but as soon as reasonably possible after that should suffice. Signed-off-by:
-
Tomeu Vizoso authored
So userspace can get feedback on any error conditions, instead of going ahead and things breaking later. Signed-off-by:
-
Sean Paul authored
Merging some panfrost fixes as well as one rockchip fix that _just_ missed feature freeze. Signed-off-by: -
Lucas Stach authored
If there is a match in the HW DB, the function is left early, before inititalizing the idle mask. Fix this by doing the init earlier, as only old GPUs, not present in the HW DB need a different idle mask. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
- SR-IOV fixes - Raven flickering fix - Misc spelling fixes - Vega20 power fixes - Freesync improvements - DC fixes Signed-off-by:
-
- 02 May, 2019 5 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2019-05-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Whitelist a register to avoid media driver from hanging Signed-off-by:
-
Lionel Landwerlin authored
Unfortunately userspace users of this API cannot be publicly disclosed yet. This commit effectively disables timeline syncobj ioctls for all drivers. Each driver wishing to support this feature will need to expose DRIVER_SYNCOBJ_TIMELINE. v2: Add uAPI capability check (Christian) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Cc: Chunming Zhou <david1.zhou@amd.com> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Lionel Landwerlin authored
We've been somewhat inconsistent when adding the new ioctl and returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncobj capibility. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2019-04-30' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Fix to Icelake CSC losing blue channel Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2019-05-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-next core: restore drm mmap_range size back to 1TB (Philip) sphinx: squash warning (Sean) Cc: Philip Yang <Philip.Yang@amd.com> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
- 01 May, 2019 9 commits
-
-
git://github.com/skeggsb/linuxDave Airlie authored
No major changes ready for this round, but a few misc fixes instead. Signed-off-by:
-
Tobias Klausmann authored
On a failed resume we may experience unrecoverable errors. Plumb the error code through to actually let the driver fail. On a reverse-prime setup this helps the drm subsystem to at least recover the integrated gpu. This can especially happen with secboot timing out, leaving the hardware in a non-functioning state. Signed-off-by:
Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Colin Ian King authored
There is a spelling mistake in a nvkm_debug message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
-
Lyude Paul authored
For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime suspend, the MMIO region that the i2c bus is on isn't accessible. On x86, the standard behavior for accessing an unavailable MMIO region is to just return ~0. Except, that turned out to be a lie. While computers with a clean concious will return ~0 in this scenario, some machines will actually completely hang a CPU on certian bad MMIO accesses. This was witnessed with someone's Lenovo ThinkPad P50, where sensors-detect attempting to access the i2c bus while the GPU was suspended would result in a CPU hang: CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1 Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017 RIP: 0010:ioread32+0x2b/0x30 Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3 48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f 40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48 RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13 RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186 RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4 RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7 R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000 R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000 FS: 00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: g94_i2c_aux_xfer+0x326/0x850 [nouveau] nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau] __i2c_transfer+0x14b/0x620 i2c_smbus_xfer_emulated+0x159/0x680 ? _raw_spin_unlock_irqrestore+0x1/0x60 ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0 ? __lock_is_held+0x59/0xa0 __i2c_smbus_xfer+0x138/0x5a0 i2c_smbus_xfer+0x4f/0x80 i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev] i2cdev_ioctl+0x1db/0x2c0 [i2c_dev] do_vfs_ioctl+0x408/0x750 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f25317f546b Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003 RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0 R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80 R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0 watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438] Yikes! While I wanted to try to make it so that accessing an i2c bus on nouveau would wake up the GPU as needed, airlied pointed out that pretty much any usecase for userspace accessing an i2c bus on a GPU (mainly for the DDC brightness control that some displays have) is going to only be useful while there's at least one display enabled on the GPU anyway, and the GPU never sleeps while there's displays running. Since teaching the i2c bus to wake up the GPU on userspace accesses is a good deal more difficult than it might seem, mostly due to the fact that we have to use the i2c bus during runtime resume of the GPU, we instead opt for the easiest solution: don't let userspace access i2c busses on the GPU at all while it's in runtime suspend. Changes since v1: * Also disable i2c busses that run over DP AUX Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Bjorn Helgaas authored
Commit 3a6536c5 ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE") added a definition of ACPI_VIDEO_NOTIFY_PROBE because <acpi/video.h> didn't supply one. Later, commit eff4a751 ("ACPI / video: Move ACPI_VIDEO_NOTIFY_* defines to acpi/video.h") moved ACPI_VIDEO_NOTIFY_PROBE and other definitions to <acpi/video.h>, so the copy in nouveau_display.c is now unnecessary. Remove the unnecessary definition from nouveau_display.c. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Hans de Goede <hdegoede@redhat.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Jon Derrick authored
If the BAR initialization failed it may leave the vmm structure in an unitialized state, leading to a null-pointer-dereference when the vmm is dereferenced during teardown. Signed-off-by:
Jon Derrick <jonathan.derrick@intel.com> Signed-off-by:
-
Jon Derrick authored
If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by:
-
Jon Derrick authored
If the BAR is zero size, it indicates it was never successfully mapped. Ensure that the BAR is valid during initialization before attempting to use it. Signed-off-by:
-
Jon Derrick authored
Check bar1's new vmm creation return value for errors. Signed-off-by:
-
- 30 Apr, 2019 1 commit
-
-
Tvrtko Ursulin authored
WaEnableStateCacheRedirectToCS context workaround configures the L3 cache to benefit 3d workloads but media has different requirements. Remove the workaround and whitelist the register to allow any userspace configure the behaviour to their liking. v2: * Remove the workaround apart from adding the whitelist. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: kevin.ma@intel.com Cc: xiaogang.li@intel.com Acked-by:
Anuj Phogat <anuj.phogat@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190418100634.984-1-tvrtko.ursulin@linux.intel.com Fixes: f63c7b48 ("drm/i915/icl: WaEnableStateCacheRedirectToCS") Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> [tursulin: Anuj reported no GPU hangs or performance regressions with old Mesa on patched kernel.] (cherry picked from commit 0fc2273b) Signed-off-by:
-
- 29 Apr, 2019 5 commits
-
-
Evan Quan authored
Power down the engine also along with disabling its DPM functionality. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Evan Quan authored
SMU will use this interface to power down the VCE engine. Signed-off-by:
-
Mario Kleiner authored
Pre-DCE12 needs special treatment for BTR / low framerate compensation for more stable behaviour: According to comments in the code and some testing on DCE-8 and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX programming with a lag of one frame, so the special BTR hw programming for intermediate fixed duration frames must be done inside the current frame at flip submission in atomic commit tail, ie. one vblank earlier, and the fixed refresh intermediate frame mode must be also terminated one vblank earlier on pre-DCE12 display engines. To achieve proper termination on < DCE-12 shift the point when the switch-back from fixed vblank duration to variable vblank duration happens from the start of VBLANK (vblank irq, as done on DCE-12+) to back-porch or end of VBLANK (handled by vupdate irq handler). We must leave the switch-back code inside VBLANK irq for DCE12+, as before. Doing this, we get much better behaviour of BTR for up-sweeps, ie. going from short to long frame durations (~high to low fps) and for constant framerate flips, as tested on DCE-8 and DCE-11. Behaviour is still not quite as good as on DCN-1 though. On down-sweeps, going from long to short frame durations (low fps to high fps) < DCE-12 is a little bit improved, although by far not as much as for up-sweeps and constant fps. v2: Fix some wrong locking, as pointed out by Nicholas. v3: Simplify if-condition in vupdate-irq - nit by Nicholas. Signed-off-by:
-
Mario Kleiner authored
The comparison of inserted_frame_duration_in_us against a duration calculated from max_refresh_in_uhz is both wrong in its math and not needed, as the min_duration_in_us value is already cached in in_out_vrr for reuse. No need to recalculate it wrongly at each invocation. Signed-off-by:
-
Nicholas Kazlauskas authored
RGB565 support isn't restricted to just the primary plane in DC, so also expose support for it on overlays. Signed-off-by:
David Francis <david.francis@amd.com> Signed-off-by:
-
