- 03 Sep, 2019 12 commits
-
-
Lyude Paul authored
Use more pointers so we don't have to write out txmsg->reply.u.path_resources each time. Also, fix line wrapping + rearrange local variables. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-10-lyude@redhat.com
-
Lyude Paul authored
Unfortunately the DP MST helpers do not have much in the way of debugging utilities. So, let's add some! This adds basic debugging output for down sideband requests that we send from the driver, so that we can actually discern what's happening when sideband requests timeout. Since there wasn't really a good way of testing that any of this worked, I ended up writing simple selftests that lightly test sideband message encoding and decoding as well. Enjoy! Changes since v1: * Clean up DO_TEST() and sideband_msg_req_encode_decode() - danvet * Get rid of pr_fmt(), just define a prefix string instead and use drm_printf() * Check highest bit of VCPI in drm_dp_decode_sideband_req() - danvet * Make the switch case order between drm_dp_decode_sideband_req() and drm_dp_encode_sideband_req() the same - danvet * Only check DRM_UT_DP - danvet * Clean up sideband_msg_req_equal() from selftests a bit, and add comments explaining why we can't just use memcmp - danvet Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Noticed this while working on adding a drm_dp_decode_sideband_req(). DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct as DP_ENUM_PATH_RESOURCES, so we can just combine their cases. Changes since v2: * Fix commit message Signed-off-by:
Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190903215702.16984-1-lyude@redhat.com
-
Lyude Paul authored
A simple convienence function that returns a drm_printer which prints using pr_err() Changes since v1: * Make __drm_printfn_err() more consistent with DRM_ERROR() - danvet Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Yes, apparently we've been testing this for every single driver load for quite a long time now. At least that means our PBN calculation is solid! Anyway, introduce self tests for MST and move this into there. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
This seems to be some leftover detritus from before the port/mstb kref cleanup and doesn't do anything anymore, so get rid of it. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Makes things easier to read. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
We can reduce the critical section in vkms_vblank_simulate under output->lock quite a lot: - hrtimer_forward_now just needs to be ordered correctly wrt drm_crtc_handle_vblank. We already access the hrtimer timestamp without locks. While auditing that I noticed that we don't correctly annotate the read there, so sprinkle a READ_ONCE to make sure the compiler doesn't do anything foolish. - drm_crtc_handle_vblank must stay under the lock to avoid races with drm_crtc_arm_vblank_event. - The access to vkms_ouptut->crc_state also must stay under the lock. - next problem is making sure the output->state structure doesn't get freed too early. First we rely on a given hrtimer being serialized: If we call drm_crtc_handle_vblank, then we are guaranteed that the previous call to vkms_vblank_simulate has completed. The other side of the coin is that the atomic updates waits for the vblank to happen before it releases the old state. Both taken together means that by the time the atomic update releases the old state, the hrtimer won't access it anymore (it might be accessing the new state at the same time, but that's ok). - state is invariant, except the few fields separate protected by state->crc_lock. So no need to hold the lock for that. - finally the queue_work. We need to make sure there's no races with the flush_work, i.e. when we call flush_work we need to guarantee that the hrtimer can't requeue the work again. This is guaranteed by the same vblank/hrtimer ordering guarantees like the reasoning above why state won't be freed too early: flush_work on the old state is called after wait_for_flip_done in the atomic commit code. Therefore we can also move everything after the output->crc_state out of the critical section. Motivated by suggestions from Rodrigo. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190719152314.7706-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's the recommended version, wait_for_vblanks is a bit a hacky interim thing that predates all the flip_done tracking. It's unfortunately still the default ... Signed-off-by:
-
Daniel Vetter authored
Noticed while reviewing code. I'm not sure whether this might or might not explain some of the missed vblank hilarity we've been seeing on various drivers (but those got tracked down to driver issues, at least mostly). I think those all go through the vblank completion event, which has unconditional barriers - it always takes the spinlock. Therefore no cc stable. v2: - Barrriers are hard, put them in in the right order (Chris). - Improve the comments a bit. v3: Ville noticed that on 32bit we might be breaking up the load/stores, now that the vblank counter has been switched over to be 64 bit. Fix that up by switching to atomic64_t. This this happens so rarely in practice I figured no need to cc: stable ... Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Keith Packard <keithp@keithp.com> References: 570e8696 ("drm: Widen vblank count to 64-bits [v3]") Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Mihail Atanassov authored
Expose node with the name 'aclk_hz' Signed-off-by:
Mihail Atanassov <mihail.atanassov@arm.com> Reviewed-by:
James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by:
Ayan kumar halder <ayan.halder@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828110342.45936-1-mihail.atanassov@arm.com
-
Heinrich Fink authored
Store the timestamp of the current vblank in the new field 'time' of the vblank trace event. If the timestamp is calculated by a driver that supports high-precision vblank timing, set the field 'high-prec' to 'true'. User space can now access actual hardware vblank times via the tracing infrastructure. Tracing applications (such as GPUVis, see [0] for related discussion), can use the newly added information to conduct a more accurate analysis of display timing. v2 Fix author name (missing last name) [0] https://github.com/mikesart/gpuvis/issues/30Reviewed-by:
Heinrich Fink <heinrich.fink@daqri.com> Signed-off-by:
-
- 02 Sep, 2019 3 commits
-
-
Linus Walleij authored
The sti_hdmi.c file include <linux/of_gpio.h> despite not even using any GPIOs. What it does use is devm_ioremap_nocache() which comes from <linux/io.h> implicitly by including that header. Fix this up by including the right header instead. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190823071428.6155-1-linus.walleij@linaro.org
-
Dariusz Marcinkiewicz authored
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector, and fill in the cec_connector_info. Changes since v2: Don't invalidate physical address before unregistering the notifier. Signed-off-by:
Dariusz Marcinkiewicz <darekm@google.com> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Cheng-Yi Chiang authored
In the designware databook, the sequence of enabling audio clock and setting format is not clearly specified. Currently, audio clock is enabled in the end of hw_param ops after setting format. On some monitors, there is a possibility that audio does not come out. Fix this by enabling audio clock in audio_startup ops before hw_param ops setting format. Signed-off-by:
Cheng-Yi Chiang <cychiang@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Jonas Karlman <jonas@kwiboo.se> Tested-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190902035435.44463-1-cychiang@chromium.org
-
- 29 Aug, 2019 2 commits
-
-
Sean Paul authored
Spec says[1] Allocated_PBN is 16 bits [1]- DisplayPort 1.2 Spec, Section 2.11.9.8, Table 2-98 Fixes: ad7f8a1f ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Lyude Paul <lyude@redhat.com> Cc: Todd Previte <tprevite@gmail.com> Cc: Dave Airlie <airlied@redhat.com> 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> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190829165223.129662-1-sean@poorly.run
-
Laurent Pinchart authored
The ingenic driver supports DPI panels only at the moment, so hardcode their type to DPI instead of Unknown. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190823212353.29369-1-laurent.pinchart@ideasonboard.com # *** extracted tags *** Reviewed-by:
Sam Ravnborg <sam@ravnborg.org>
-
- 28 Aug, 2019 8 commits
-
-
Boris Brezillon authored
This is part of our attempt to make the bridge chain a double-linked list based on the generic list helpers. In order to do that, we must patch all drivers manipulating the encoder->bridge field directly. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190826152649.13820-9-boris.brezillon@collabora.com
-
Boris Brezillon authored
We are about to add a drm_bridge_state that inherits from drm_private_state which is defined in drm_atomic.h. Problem is, drm_atomic.h includes drm_crtc.h which in turn includes drm_bridge.h, leading to "drm_private_state has incomplete type" error. Let's force all users of the drm_bridge API to explicitly include drm_bridge.h. Signed-off-by:
-
Neil Armstrong authored
Add the suspend and resume hooks to: - save and disable the entire DRM driver on suspend - re-init the entire VPU subsystem on resume, to recover CRTC and pixel generator functionnal usage after DDR suspend, then recover DRM driver state Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827095825.21015-3-narmstrong@baylibre.com
-
Neil Armstrong authored
Add the suspend and resume hooks to: - reset the whole HDMI glue and HDMI controller on suspend - re-init the HDMI glue and HDMI controller on resume The HDMI glue init is refactored to be re-used from the resume hook. It makes usage of dw_hdmi_resume() to recover a functionnal DDC bus. Signed-off-by:
-
Stephen Rothwell authored
Fixes: 3e93bc2a ("drm/virtio: make resource id workaround runtime switchable.") Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Link: http://patchwork.freedesktop.org/patch/msgid/20190828185516.22b03da8@canb.auug.org.auSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gerd Hoffmann authored
Split virtqueue_kick() call into virtqueue_kick_prepare(), which requires serialization, and virtqueue_notify(), which does not. Move the virtqueue_notify() call out of the critical section protected by the queue lock. This avoids triggering a vmexit while holding the lock and thereby fixes a rather bad spinlock contention. Suggested-by:
Chia-I Wu <olvaffe@gmail.com> Signed-off-by:
-
Gerd Hoffmann authored
Make the queue functions return void, none of the call sites checks the return value. Signed-off-by:
-
Gerd Hoffmann authored
Use drm_atomic_helper_check_plane_state() to sanity check the plane state. Signed-off-by:
-
- 27 Aug, 2019 4 commits
-
-
Dariusz Marcinkiewicz authored
Fill in the connector info, allowing userspace to associate the CEC device with the drm connector. Tested on a Raspberry Pi 3B. Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190823112427.42394-2-hverkuil-cisco@xs4all.nl
-
Dariusz Marcinkiewicz authored
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector, and fill in the cec_connector_info. Signed-off-by:
-
Dariusz Marcinkiewicz authored
Pass the connector info to the CEC adapter. This makes it possible to associate the CEC adapter with the corresponding drm connector. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Gerd Hoffmann authored
Also update the comment with a reference to the virglrenderer fix. Signed-off-by:
-
- 26 Aug, 2019 2 commits
-
-
Christophe JAILLET authored
If we don't find any matching components, we should go through the error handling path, in order to free some resources. Fixes: ca5be902 ("drm/mcde: Fix uninitialized variable") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Dan Carpenter authored
This code will likely crash if we try to do a zero byte write. The code looks like this: /* strip trailing whitespace */ for (i = count - 1; i > 0; i--) if (isspace(buf[i])) ... We're writing zero bytes so count = 0. You would think that "count - 1" would be negative one, but because "i" is unsigned it is a large positive numer instead. The "i > 0" condition is true and the "buf[i]" access will be out of bounds. The fix is to make "i" signed and now everything works as expected. The upper bound of "count" is capped in __kernel_write() at MAX_RW_COUNT so we don't have to worry about it being higher than INT_MAX. Fixes: 02dd95fe ("drm/tinydrm: Add MIPI DBI support") Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> [noralf: Adjust title] Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190821072456.GJ26957@mwanda
-
- 24 Aug, 2019 2 commits
-
-
Laurent Pinchart authored
Instead of requiring all drivers to set the dev and funcs fields of drm_panel manually after calling drm_panel_init(), pass the data as arguments to the function. This simplifies the panel drivers, and will help future refactoring when adding new arguments to drm_panel_init(). The panel drivers have been updated with the following Coccinelle semantic patch, with manual inspection to verify that no call to drm_panel_init() with a single argument still exists. @@ expression panel; expression device; identifier ops; @@ drm_panel_init(&panel + , device, &ops ); ... ( -panel.dev = device; -panel.funcs = &ops; | -panel.funcs = &ops; -panel.dev = device; ) Suggested-by:
-
Laurent Pinchart authored
Panels must be initialised with drm_panel_init(). Add the missing function call in the panel-raspberrypi-touchscreen.c and panel-sitronix-st7789v.c drivers. Signed-off-by:
-
- 23 Aug, 2019 7 commits
-
-
Alyssa Rosenzweig authored
While newer kbase include only the numbers of errata, older kbase releases included one-line descriptions for each errata, which is useful for those working on the driver. Import these descriptions. Most are from kbase verbatim; a few I edited for clarity. v2: Wrote a description for the workaround of an issue whose cause is still unknown (Stephen). Errata which pertain to newer models unsupported by the mainline driver, for which Arm has not yet released errata information, have been removed from the issue list as the kernel need not concern itself with these. v3: Readded errata not yet handled, adding descriptions based on the workarounds in the latest kbase release. Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190823155149.7272-1-alyssa.rosenzweig@collabora.com
-
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:
Steven Price <steven.price@arm.com> Acked-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:
-
Rob Herring authored
Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the primary reviewers already. Cc: Steven Price <steven.price@arm.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-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:
-
