- 19 Sep, 2019 5 commits
-
-
Steven Price authored
When handling a GPU page fault addr_to_drm_mm_node() is used to translate the GPU address to a buffer object. However it is possible for the buffer object to be freed after the function has returned resulting in a use-after-free of the BO. Change addr_to_drm_mm_node to return the panfrost_gem_object with an extra reference on it, preventing the BO from being freed until after the page fault has been handled. Signed-off-by:
Steven Price <steven.price@arm.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190913160310.50444-1-steven.price@arm.com
-
Steven Price authored
devm_regulator_get() is now used to populate pfdev->regulator which ensures that this cannot be NULL (a dummy regulator will be returned if necessary). So remove the checks in panfrost_devfreq_target(). Signed-off-by:
-
Mark Brown authored
The panfrost driver requests a supply using regulator_get_optional() but both the name of the supply and the usage pattern suggest that it is being used for the main power for the device and is not at all optional for the device for function, there is no meaningful handling for absent supplies. Such regulators should use the vanilla regulator_get() interface, it will ensure that even if a supply is not described in the system integration one will be provided in software. Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Sean Paul authored
Currently the self refresh idle timer is a const set by the crtc. This is fine if the self refresh entry/exit times are well-known for all panels used on that crtc. However panels and workloads can vary quite a bit, and a timeout which works well for one doesn't work well for another. In the extreme, if the timeout is too short we could get in a situation where the self refresh exits are taking so long we queue up a self refresh entry before the exit commit is even finished. This patch changes the idle timeout to a moving average of the entry times + a moving average of exit times + the crtc constant. This patch was tested on rockchip, with a kevin CrOS panel the idle delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On the same board, the bob panel idle delay lands around ~340ms (90 entry + 150 exit + 100 const). WRT the dedicated mutex in self_refresh_data, it would be nice if we could rely on drm_crtc.mutex to protect the average times, but there are a few reasons why a separate lock is a better choice: - We can't rely on drm_crtc.mutex being held if we're doing a nonblocking commit - We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us whether the lock was already held in the acquire context (it eats -EALREADY), so we can't tell if we should drop it or not - We don't need such a heavy-handed lock for what we're trying to do, commit ordering doesn't matter, so a point-of-use lock will be less contentious Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-sean@poorly.run Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-2-sean@poorly.run Changes in v2: - Migrate locking explanation from comment to commit msg (Daniel) - Turf constant entry delay and multiply the avg times by 2 (Daniel)
-
Sean Paul authored
Artifacts of previous revisions. Reviewed-by:
-
- 18 Sep, 2019 4 commits
-
-
Daniel Vetter authored
It's the only flag anyone actually cares about. Plus if we're unlucky, the atomic ioctl might need a different flag for async flips. So better to abstract this away from the uapi a bit. Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: David Francis <David.Francis@amd.com> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190903190642.32588-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's never been wired up. Only userspace that tried to use it (and didn't actually check whether anything works, but hey it builds) is the -modesetting atomic implementation. And we just shut that up. If there's anyone else then we need to silently accept this flag no matter what, and find a new one. Because once a flag is tainted, it's lost. Reviewed-by:
-
Daniel Vetter authored
The -modesetting ddx has a totally broken idea of how atomic works: - doesn't disable old connectors, assuming they get auto-disable like with the legacy setcrtc - assumes ASYNC_FLIP is wired through for the atomic ioctl - not a single call to TEST_ONLY Iow the implementation is a 1:1 translation of legacy ioctls to atomic, which is a) broken b) pointless. We already have bugs in both i915 and amdgpu-DC where this prevents us from enabling neat features. If anyone ever cares about atomic in X we can easily add a new atomic level (req->value == 2) for X to get back the shiny toys. Since these broken versions of -modesetting have been shipping, there's really no other way to get out of this bind. v2: - add an informational dmesg output (Rob, Ajax) - reorder after the DRIVER_ATOMIC check to avoid useless noise (Ilia) - allow req->value > 2 so that X can do another attempt at atomic in the future v3: Go with paranoid, insist that the X should be first (suggested by Rob) Cc: Ilia Mirkin <imirkin@alum.mit.edu> References: https://gitlab.freedesktop.org/xorg/xserver/issues/629 References: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180 References: abbc0697 ("drm/fb: revert the i915 Actually configure untiled displays from master") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1) Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> (v1) Cc: Michel Dänzer <michel@daenzer.net> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Acked-by:
Adam Jackson <ajax@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Rob Clark <robdclark@gmail.com> Acked-by:
Rob Clark <robdclark@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Daniel Vetter authored
commit 4f5368b5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 14 08:17:23 2019 +0200 drm/kms: Catch mode_object lifetime errors uncovered a bit a mess in dp drivers. Most drivers (from a quick look, all except i915) register all the dp stuff in their init code, which is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up, because drm_dp_aux_register tries to add a child to a device in sysfs (the connector) which doesn't even exist yet. No one seems to have cared thus far. But with the above change I also moved the setting of dev->registered after the ->load callback, in an attempt to keep old drivers from hitting any WARN_ON backtraces. But that moved radeon.ko from the "working, by accident" to "now also broken" category. Since this is a huge mess I figured a revert would be simplest. But this check has already caught issues in i915: commit 1b9bd096 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Aug 20 19:16:57 2019 +0300 drm/i915: Do not create a new max_bpc prop for MST connectors Hence I'd like to retain it. Fix the radeon regression by moving the setting of dev->registered back to were it was, and stop the backtraces with an explicit check for dev->driver->load. Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The next patch will improve the kerneldoc and add a todo entry for this. Fixes: 4f5368b5 ("drm/kms: Catch mode_object lifetime errors") Cc: Sean Paul <sean@poorly.run> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
Michel Dänzer <michel@daenzer.net> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Tested-by:
-
- 13 Sep, 2019 1 commit
-
-
Rob Clark authored
This reverts commit 83f35bc3. There are at least two DSI controller drivers which relies on the old behaviour of adv7511 driver. To avoid platform breakage this patch should be reverted. This is a temporary solution, as it blocks adv7511 usage with other platforms. Assumption that DSI device driver (bridge/panel) should first expose drm_bridge/drm_panel object, then look for DSI bus is just incorrect - it can work with devices controlled via i2c but it cannot work with devices controlled via DSI - they will not be able to probe. To solve the issue following steps should be performed: - rework reverted patch allowing co-operation with broken DSI controller drivers - with simple/ugly workaround, - fix controller drivers and then remove workaround. Signed-off-by:
Rob Clark <robdclark@chromium.org> [a.hajda: changed commit message] Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829180836.14453-1-robdclark@gmail.com
-
- 04 Sep, 2019 1 commit
-
-
Linus Walleij authored
There were bugs in the DSI transfer (read and write) function as it was only tested with displays ever needing a single byte to be written. Fixed it up and tested so we can now write messages of up to 16 bytes and read up to 4 bytes from the display. Tested with a Sony ACX424AKP display: this display now self- identifies and can control backlight in command mode. Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 5fc537bf ("drm/mcde: Add new driver for ST-Ericsson MCDE") Reviewed-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190903170804.17053-1-linus.walleij@linaro.org
-
- 30 Aug, 2019 8 commits
-
-
Rob Herring authored
With the introduction of the as_lock to serialize address space registers, the hwaccess_lock is only used within the job code and is not protecting anything. panfrost_job_hw_submit() only accesses registers for 1 job slot and it's already serialized by drm_sched. Fixes: 7282f764 ("drm/panfrost: Implement per FD address spaces") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
-
Rob Herring authored
Currently, page tables are freed without disabling the address space first. This probably is fine as we'll switch to new page tables when the address space is allocated again and runtime PM suspend will reset the GPU clearing the registers. However, it's better to clean up after ourselves. There is also a problem that we could be accessing the h/w in tlb_inv_context() when suspended. Rework the disable code to make sure we flush caches/TLBs and disable the address space before freeing the page tables if we are not suspended. As the tlb_inv_context() hook is only called when freeing the page tables and we do a flush before disabling the AS, lets remove the flush from tlb_inv_context and avoid any runtime PM issues. Fixes: 7282f764 ("drm/panfrost: Implement per FD address spaces") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
-
Rob Herring authored
It's not entirely clear if this is required, but add a flush of GPU caches and TLBs before we change an address space to new page tables. Fixes: 7282f764 ("drm/panfrost: Implement per FD address spaces") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Rob Herring authored
In preparation to call mmu_hw_do_operation with the as_lock already held, Add a mmu_hw_do_operation_locked function. Fixes: 7282f764 ("drm/panfrost: Implement per FD address spaces") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Rob Herring authored
There is no point in resuming the h/w just to do flush operations and doing so takes several locks which cause lockdep issues with the shrinker. Rework the flush operations to only happen when the h/w is already awake. This avoids taking any locks associated with resuming which trigger lockdep warnings. Fixes: 013b6510 ("drm/panfrost: Add madvise and shrinker support") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Rob Herring authored
There's no need to serialize io-pgtable calls and the as_lock is sufficient to serialize flush operations, so we can remove the per page table lock. Fixes: 7282f764 ("drm/panfrost: Implement per FD address spaces") Suggested-by:
-
Rob Herring authored
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should not happen until the job completes. It works currently because we are relying on the autosuspend timeout to keep the h/w enabled. Fixes: f3ba9122 ("drm/panfrost: Add initial panfrost driver") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Rob Herring authored
There's a few issues with the runtime PM initialization. The documentation states pm_runtime_set_active() should be called before pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU before panfrost_perfcnt_init() is called which touches the h/w. The autosuspend delay keeps things from breaking. There's no need explicitly power off the GPU only to wake back up with pm_runtime_get_sync(). Just delaying pm_runtime_enable to the end of probe is sufficient. Lets move all the runtime PM calls into the probe() function so they are all in one place and are done after all initialization. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by:
-
- 28 Aug, 2019 5 commits
-
-
Rob Herring authored
Lockdep reports a circular locking dependency with pages_lock taken in the shrinker callback. The deadlock can't actually happen with current users at least as a BO will never be purgeable when pages_lock is held. To be safe, let's use mutex_trylock() instead and bail if a BO is locked already. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Rob Herring authored
Lockdep reports a circular locking dependency with pages_lock taken in the shrinker callback. The deadlock can't actually happen with current users at least as a BO will never be purgeable when pages_lock is held. To be safe, let's use mutex_trylock() instead and bail if a BO is locked already. WARNING: possible circular locking dependency detected 5.3.0-rc1+ #100 Tainted: G L ------------------------------------------------------ kswapd0/171 is trying to acquire lock: 000000009b9823fd (&shmem->pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40 but task is already holding lock: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}: fs_reclaim_acquire.part.18+0x34/0x40 fs_reclaim_acquire+0x20/0x28 __kmalloc_node+0x6c/0x4c0 kvmalloc_node+0x38/0xa8 drm_gem_get_pages+0x80/0x1d0 drm_gem_shmem_get_pages+0x58/0xa0 drm_gem_shmem_get_pages_sgt+0x48/0xd0 panfrost_mmu_map+0x38/0xf8 [panfrost] panfrost_gem_open+0xc0/0xe8 [panfrost] drm_gem_handle_create_tail+0xe8/0x198 drm_gem_handle_create+0x3c/0x50 panfrost_gem_create_with_handle+0x70/0xa0 [panfrost] panfrost_ioctl_create_bo+0x48/0x80 [panfrost] drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x90/0x168 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc -> #0 (&shmem->pages_lock){+.+.}: __lock_acquire+0xa2c/0x1d70 lock_acquire+0xdc/0x228 __mutex_lock+0x8c/0x800 mutex_lock_nested+0x1c/0x28 drm_gem_shmem_purge+0x20/0x40 panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost] do_shrink_slab+0x208/0x500 shrink_slab+0x10c/0x2c0 shrink_node+0x28c/0x4d8 balance_pgdat+0x2c8/0x570 kswapd+0x22c/0x638 kthread+0x128/0x130 ret_from_fork+0x10/0x18 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&shmem->pages_lock); lock(fs_reclaim); lock(&shmem->pages_lock); *** DEADLOCK *** 3 locks held by kswapd0/171: #0: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 #1: 00000000ceb37808 (shrinker_rwsem){++++}, at: shrink_slab+0xbc/0x2c0 #2: 00000000f31efa81 (&pfdev->shrinker_lock){+.+.}, at: panfrost_gem_shrinker_scan+0x34/0x180 [panfrost] Fixes: 17acb9f3 ("drm/shmem: Add madvise state and purge helpers") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: -
Rob Herring authored
Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the backing pages have already been released by the shrinker. The result is the following abort: Unable to handle kernel paging request at virtual address ffff8000098ed000 Mem abort info: ESR = 0x96000147 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000147 CM = 1, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000002f51000 [ffff8000098ed000] pgd=00000000401f8003, pud=00000000401f7003, pmd=00000000401b1003, pte=00e80000098ed712 Internal error: Oops: 96000147 [#1] SMP Modules linked in: panfrost gpu_sched CPU: 5 PID: 902 Comm: gnome-shell Not tainted 5.3.0-rc1+ #95 Hardware name: 96boards Rock960 (DT) pstate: 40000005 (nZcv daif -PAN -UAO) pc : __dma_inv_area+0x40/0x58 lr : arch_sync_dma_for_cpu+0x28/0x30 sp : ffff00001321ba30 x29: ffff00001321ba30 x28: ffff00001321bd08 x27: 0000000000000000 x26: 0000000000000009 x25: 0000ffffc1f86170 x24: 0000000000000000 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000021000 x20: ffff80003bb2d810 x19: 00000000098ed000 x18: 0000000000000000 x17: 0000000000000000 x16: ffff800023fd9480 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 00000000fffb9fff x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800023fd9c18 x7 : 0000000000000000 x6 : 00000000ffffffff x5 : 0000000000000000 x4 : 0000000000021000 Purging 5693440 bytes x3 : 000000000000003f x2 : 0000000000000040 x1 : ffff80000990e000 x0 : ffff8000098ed000 Call trace: __dma_inv_area+0x40/0x58 dma_direct_sync_single_for_cpu+0x7c/0x80 dma_direct_unmap_page+0x80/0x88 dma_direct_unmap_sg+0x54/0x80 drm_gem_shmem_free_object+0xfc/0x108 panfrost_gem_free_object+0x118/0x128 [panfrost] drm_gem_object_free+0x18/0x90 drm_gem_object_put_unlocked+0x58/0x80 drm_gem_object_handle_put_unlocked+0x64/0xb0 drm_gem_object_release_handle+0x70/0x98 drm_gem_handle_delete+0x64/0xb0 drm_gem_close_ioctl+0x28/0x38 drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x88/0x150 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc Code: 8a230000 54000060 d50b7e20 14000002 (d5087620) Fixes: 17acb9f3 ("drm/shmem: Add madvise state and purge helpers") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
-
Rob Herring authored
Calls to panfrost_device_fini() access the h/w, but we already done a pm_runtime_put_sync_autosuspend() beforehand. This only works if the autosuspend delay is long enough. A 0ms delay will hang the system when removing the device. Fix this by moving the pm_runtime_put_sync_suspend() after the panfrost_device_fini() call. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Steven Price authored
When modifying panfrost_devfreq_target() to support a device without a regulator defined I missed the check on the error path. Let's add it. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: e21dd290 ("drm/panfrost: Enable devfreq to work without regulator") Signed-off-by:
-
- 27 Aug, 2019 5 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
drm-next-5.4-2019-08-23: amdgpu: - Enable power features on Navi12 - Enable power features on Arcturus - RAS updates - Initial Renoir APU support - Enable power featyres on Renoir - DC gamma fixes - DCN2 fixes - GPU reset support for Picasso - Misc cleanups and fixes scheduler: - Possible race fix Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823202620.3870-1-alexander.deucher@amd.com
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: dma-fence selftests Driver Changes: - kirin: Various cleanups and reworks - komeda: Add support for DT memory-regions - meson: Rely on the compatible to detect vpu features - omap: Implement alpha and pixel blend mode properties - panfrost: Implement per-fd address spaces, various fixes - rockchip: DSI DT binding rework - fbdev: Various cleanups Signed-off-by:
-
https://github.com/xin3liang/linuxDave Airlie authored
Three small cleanup and fix patches for 5.4 hisilicon hibmc driver. I have tested and verified on taishan 2280v1/v2 machines. Signed-off-by:
-
git://git.pengutronix.de/pza/linuxDave Airlie authored
drm/imx: IPUv3 image converter fixes and improvements Fix image converter seam handling for 1024x1024 pixel hardware limitation at the main processing section input, improve error handling, and slightly optimize for 1:1 conversions. Add support for newly defined 32-bit RGB V4L2 pixel formats. Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
- More TGL enabling work (Michel, Jose, Lucas) - Fixes on DP MST (Ville) - More GTT and Execlists fixes and improvements (Chris) - Code style clean-up on hdmi and dp side (Jani) - Fix null pointer dereferrence (Xiong) - Fix a couple of missing serialization on selftests (Chris) - More vm locking rework (Chris) drm-intel-next-2019-08-20: - GuC and HuC related fixes and improvements (Daniele, Michal) - Improve debug with more engine information and rework on debugfs files (Chris, Stuart) - Simplify appearture address handling (Chris) - Other fixes and cleanups around engines and execlists (Chris) - Selftests fixes (Matt, Chris) - Gen11 cache flush related fixes and improvements (Mika) - More work around requests, timelines and locks to allow removal of struct_mutex (Chris) - Add missing CML PCI ID (Anusha) - More work on the new i915 buddy allocator (Matt) - More headers, files and directories reorg (Daniele) - Improvements on ggtt’s get pdp (Mika) - Fix GPU reset (Chris) - Fix GPIO pins on gen11 (Matt) - Fix HW readout for crtc_clock in HDMI mode (Imre) - Sanitize display Phy during unitit to workaround messages of HW state change during suspend (Imre) - Be defensive when starting vma activity (Chris) - More Tiger Lake enabling work (Michel, Daniele, Lucas) - Relax pd_used assertion (Chris) drm-intel-next-2019-08-13: - More Tiger Lake enabling work (Lucas, Jose, Tomasz, Michel, Jordan, Anusha, Vandita) - More selftest organization reworks, fixes and improvements (Lucas, Chris) - Simplifications on GEM code like context and cleanup_early (Chris, Daniele) - GuC and HuC related fixes and improvements (Daniele, Michal, Chris) - Some clean up and fixes on headers, Makefile, and generated files (Lucas, Jani) - MOCS setup clean up (Tvrtko) - More Elkhartlake enabling work (Jose, Matt) - Fix engine reset by clearing in flight execlists requests (Chris) - Fix possible memory leak on intel_hdcp_auth_downstream (Wei) - Introduce intel_gt_runtime_suspend/resume (Daniele) - PMU improvements (Tvrtko) - Flush extra hard after writing relocations through the GTT (Chris) - Documentations fixes (Michal, Chris) - Report dma_reserv allocation failure (Chris) - Improvements around shrinker (Chris) - More improvements around engine handling (Chris) - Also more s/dev_priv/i915 (Chris) - Abstract display suspend/resume operations (Rodrigo/Jani) - Drop VM_IO from GTT mappings (Chris) - Fix some NULL vs IS_ERR conditions (Dan) - General improvements on error state (Chris) - Isolate i915_getparam_iocrtl to its own file (Chris) - Perf OA object refactor (Umesh) - Ignore central i915->kernel_context and allocate it directly (Chris) - More fixes and improvements around wakerefs (Chris) - Clean-up and improvements around debugfs (Chris) - Free the imported shmemfs file for phys objects (Chris) - Many other fix and cleanups around engines and execlists (Chris) - Split out uncore_mmio_debug (Daniele) - Memory management fixes for blk and gtt (Matt) - Introduction of buddy allocator to handle huge-pages for GTT (Matt) - Fix ICL and TGL PG3 power domains (Anshuman) - Extract GT IRQ to gt/ (Andi) - Drop last_fence tracking in favor of whole vma->active (Chris) - Make overlay to use i915_active instead of i915_active_request (Chris) - Move misc display IRQ handling to its own function (Jose) - Introduce new _TRANS2() macro in preparation for some coming PSR related work (Jose) Signed-off-by:
-
- 26 Aug, 2019 3 commits
-
-
Matthew Ruffell authored
Hisilicon developed hibmc_drm for their arm64 based soc and did not intend for this driver to be used on any other architecture than arm64. Using it on amd64 leads to incorrect video modes being used, making the screen unreadable, forcing users to manually blacklist the module on the kernel command line to use the d-i server installer or any graphical sessions. Make CONFIG_DRM_HISI_HIBMC firmly depend on ARM64 to ensure it is not built for other architectures. Signed-off-by:
Matthew Ruffell <matthew.ruffell@canonical.com> Signed-off-by:
Xinliang Liu <z.liuxinliang@hisilicon.com>
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
YueHaibing authored
Remove boilerplate code by using macro module_pci_driver. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
- 23 Aug, 2019 8 commits
-
-
Anthony Koo authored
Signed-off-by:
Anthony Koo <Anthony.Koo@amd.com> Reviewed-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
hersen wu authored
[WHY] value of dchub_ref_clock is decided by dchubbub global timer settings which is programmed by vbios command table disp_init. for multi-GPU case, vbios is posted only for primary GPU. without vbios posted for the secondary GPU, value of dchub_ref_clock is not set properly. this value will affect dcn bandwidth calcuation and cause underflow. user will see screen flicking during driver installation for dual GPU case. [HOW] dc init_hw always call vbios command table disp_init to make sure dchubbub global timer is configured and enable. Signed-off-by:
hersen wu <hersenxs.wu@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Joshua Aberback authored
[Why] The register LVTMA_PWRSEQ_CNTL is used to determine the power state of the embedded display. Currently we do not actually read this register's values, so during power down we think that this display is already off, so we skip calling into VBIOS to actually turn it off. [How] - add relevant fields to shift / mask initialization Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Jun Lei authored
[why] Previous workaround to prevent a vsync flip to be converted to immediate flip is no longer needed, and is risky because there are cases where it can result in infinite loop. [how] Remove wait loop (which is potentially infinite) before locking pipe Signed-off-by:
Eric Yang <eric.yang2@amd.com> Acked-by:
-
Derek Lai authored
[Why] We should be using the ddc_num from res_caps. As the pipe count != number of i2c resources. [How] Use ddc_num from res_cap instead of pipe count. Signed-off-by:
Derek Lai <Derek.Lai@amd.com> Reviewed-by:
-
Bayan Zabihiyan authored
[Why] Existing HW Features, HW Diags test requested that the registers be exposed. [How] Add V_TOTAL_MID to existing DC structures. Make sure values are passed down throughout DC Add Register definition. Program the additional registers Add additional Logic for V_TOTAL_CONTROL. Signed-off-by:
Bayan Zabihiyan <bayan.zabihiyan@amd.com> Reviewed-by:
-
Jun Lei authored
[why] Calculating DCFCLK DS time requires calculating delivery time for luma/chroma, but this value is not calculated in DMLv2, it was inadvertently removed when porting DMLv2 [how] Add the calculation back Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
David Francis authored
DRM provides drm_dp_mst_dump_topology, which prints useful information about MST devices Hook this up to a debugfs file named amdgpu_mst_topology Signed-off-by:
David Francis <David.Francis@amd.com> Acked-by:
-
