kernel/linux.git/drivers/gpu/drm/panfrost, branch v5.5.10

drm/panfrost: Don't try to map on error faults

2020-03-12T06:18:40+00:00

commit eb9d8ddbc107d02e489681f9dcbf93949e1a99a4 upstream. If the exception type isn't a translation fault, don't try to map and instead go straight to a terminal fault. Otherwise, we can get flooded by kernel warnings and further faults. Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Rob Herring Signed-off-by: Tomeu Vizoso Reviewed-by: Steven Price Reviewed-by: Tomeu Vizoso Acked-by: Alyssa Rosenzweig Link: https://patchwork.freedesktop.org/patch/msgid/20200212202236.13095-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman

drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context

2020-02-28T16:23:33+00:00

commit dde2bb2da01e96c17f0a44b4a3cf72a30e66e3ef upstream. We need to use the AS attached to the opened FD when dumping counters. Reported-by: Antonio Caggiano Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Tested-by: Antonio Caggiano Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20200206141327.446127-1-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Make sure the shrinker does not reclaim referenced BOs

2020-02-19T18:54:07+00:00

commit 7e0cf7e9936c4358b0863357b90aa12afe6489da upstream. Userspace might tag a BO purgeable while it's still referenced by GPU jobs. We need to make sure the shrinker does not purge such BOs until all jobs referencing it are finished. Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-9-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Add the panfrost_gem_mapping concept

2020-01-21T16:32:55+00:00

With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and opened in different context or if the dmabuf is self-imported. The current implementation does not take case into account, and attaches the mapping directly to the panfrost_gem_object. Let's create a panfrost_gem_mapping struct and allow multiple mappings per BO. The mappings are refcounted which helps solve another problem where mappings were torn down (GEM handle closed by userspace) while GPU jobs accessing those BOs were still in-flight. Jobs now keep a reference on the mappings they use. v2 (robh): - Minor review comment clean-ups from Steven - Use list_is_singular helper - Just WARN if we add a mapping when madvise state is not WILLNEED. With that, drop the use of object_name_lock. v3 (robh): - Revert returning list iterator in panfrost_gem_mapping_get() Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: Signed-off-by: Boris Brezillon Signed-off-by: Rob Herring Acked-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20200116021554.15090-1-robh@kernel.org

Merge tag 'drm-misc-next-fixes-2019-12-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

2019-12-13T04:33:00+00:00

-mgag200: more startadd mitigation (Thomas) -panfrost: devfreq fix + several memory fixes (Steven, Boris) Cc: Boris Brezillon Cc: Steven Price Cc: Thomas Zimmermann Signed-off-by: Dave Airlie From: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191212140145.GA145200@art_vandelay

drm/panfrost: Open/close the perfcnt BO

2019-12-06T17:06:20+00:00

Commit a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") moved the drm_mm_insert_node_generic() call to the gem->open() hook, but forgot to update perfcnt accordingly. Patch the perfcnt logic to call panfrost_gem_open/close() where appropriate. Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Acked-by: Alyssa Rosenzweig Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-6-boris.brezillon@collabora.com

drm/panfrost: Fix a race in panfrost_gem_free_object()

2019-12-06T17:06:16+00:00

panfrost_gem_shrinker_scan() might purge a BO (release the sgt and kill the GPU mapping) that's being freed by panfrost_gem_free_object() if we don't remove the BO from the shrinker list at the beginning of panfrost_gem_free_object(). Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Acked-by: Alyssa Rosenzweig Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-5-boris.brezillon@collabora.com

drm/panfrost: Fix a BO leak in panfrost_ioctl_mmap_bo()

2019-12-06T17:06:11+00:00

We should release the reference we grabbed when an error occurs. Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Acked-by: Alyssa Rosenzweig Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-4-boris.brezillon@collabora.com

drm/panfrost: Fix a race in panfrost_ioctl_madvise()

2019-12-06T17:05:52+00:00

If 2 threads change the MADVISE property of the same BO in parallel we might end up with an shmem->madv value that's inconsistent with the presence of the BO in the shrinker list. The easiest solution to fix that is to protect the drm_gem_shmem_madvise() call with the shrinker lock. Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Acked-by: Alyssa Rosenzweig Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-3-boris.brezillon@collabora.com

drm/panfrost: devfreq: Round frequencies to OPPs

2019-12-06T17:05:39+00:00

Currently when setting a frequency in panfrost_devfreq_target the returned frequency is the actual frequency that the clock driver reports (the return of clk_get_rate()). However, where the provided OPPs don't precisely match the frequencies that the clock actually achieves devfreq will then complain (repeatedly): devfreq devfreq0: Couldn't update frequency transition information. To avoid this change panfrost_devfreq_target() to fetch the opp using devfreq_recommened_opp() and not actually query the clock for the frequency. A similar problem exists with panfrost_devfreq_get_cur_freq(), but in this case because the function is optional we can just remove it and devfreq will fall back to using the previously set frequency. Fixes: 221bc77914cb ("drm/panfrost: Use generic code for devfreq") Signed-off-by: Steven Price Reviewed-by: Alyssa Rosenzweig Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20191118173002.32015-1-steven.price@arm.com