kernel/linux.git/drivers/gpu/drm/omapdrm, branch v4.19.16

drm/omap: fix memory barrier bug in DMM driver

2018-11-21T08:19:10+00:00

[ Upstream commit 538f66ba204944470a653a4cccc5f8befdf97c22 ] A DMM timeout "timed out waiting for done" has been observed on DRA7 devices. The timeout happens rarely, and only when the system is under heavy load. Debugging showed that the timeout can be made to happen much more frequently by optimizing the DMM driver, so that there's almost no code between writing the last DMM descriptors to RAM, and writing to DMM register which starts the DMM transaction. The current theory is that a wmb() does not properly ensure that the data written to RAM is observable by all the components in the system. This DMM timeout has caused interesting (and rare) bugs as the error handling was not functioning properly (the error handling has been fixed in previous commits): * If a DMM timeout happened when a GEM buffer was being pinned for display on the screen, a timeout error would be shown, but the driver would continue programming DSS HW with broken buffer, leading to SYNCLOST floods and possible crashes. * If a DMM timeout happened when other user (say, video decoder) was pinning a GEM buffer, a timeout would be shown but if the user handled the error properly, no other issues followed. * If a DMM timeout happened when a GEM buffer was being released, the driver does not even notice the error, leading to crashes or hang later. This patch adds wmb() and readl() calls after the last bit is written to RAM, which should ensure that the execution proceeds only after the data is actually in RAM, and thus observable by DMM. The read-back should not be needed. Further study is required to understand if DMM is somehow special case and read-back is ok, or if DRA7's memory barriers do not work correctly. Signed-off-by: Tomi Valkeinen Signed-off-by: Peter Ujfalusi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm: drop _mode_ from drm_mode_connector_attach_encoder

2018-07-13T16:40:27+00:00

Again to align with the usual prefix of just drm_connector_. Again done with sed + manual fixup for indent issues. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-7-daniel.vetter@ffwll.ch

drm: drop _mode_ from update_edit_property()

2018-07-13T16:40:27+00:00

Just makes it longer, and for most things in drm_connector.[hc] we just use the drm_connector_ prefix. Done with sed + a bit of manual fixup for the indenting. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-6-daniel.vetter@ffwll.ch

Merge tag 'omapdrm-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next

2018-07-05T20:29:24+00:00

omapdrm changes for 4.19 * Workaround for DRA7 errata i932 * Fix mm_list locking * Cleanups Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/88b2e77f-9646-d15f-645b-ba45af2a1966@ti.com

drm/omap: gem: Switch to gem_free_object_unlocked()

2018-06-28T10:41:05+00:00

The only thing that omap_gem_free_object does that might need the magic protection of struct_mutex (of keeping all objects alive if that lock is held, even if the last reference is gone) is the mm_list manipulation. This is already protected by the separate omapdrm->list_lock, which means that struct_mutex is not needed by omapdrm. We can switch to gem_free_object_unlocked() Signed-off-by: Daniel Vetter Reviewed-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm/omap: gem: Fix mm_list locking

2018-06-28T10:41:05+00:00

- None of the list walkings where protected. - Switch to a mutex since the list walking at device resume time can sleep when pinning buffers through the tiler. Only thing we need to be careful with here is that while we walk the list we can't unreference any gem objects, since the final unref would result in a recursive deadlock. But the only functions that walk the list is the device resume and debugfs dumping, so all safe. Signed-off-by: Daniel Vetter Reviewed-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen

drm/omap: gem: Replace struct_mutex usage with omap_obj private lock

2018-06-28T10:41:05+00:00

The DRM device struct_mutex is used to protect against concurrent GEM object operations that deal with memory allocation and pinning. All those operations are local to a GEM object and don't need to be serialized across different GEM objects. Replace the struct_mutex with a local omap_obj.lock or drop it altogether where not needed. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen

drm/omap: gem: Don't take struct_mutex to get GEM object mmap offset

2018-06-28T10:41:05+00:00

GEM objects mmap offsets are created by calling drm_gem_create_mmap_offset_size() that doesn't need struct_mutex protection as it includes its own locking, based on a size that is static across the object's life time. Remove the unneeded struct_mutex locking. Signed-off-by: Laurent Pinchart Reviewed-by: Daniel Vetter Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen

drm/omap: gem: Merge __omap_gem_get_pages() and omap_gem_attach_pages()

2018-06-28T10:41:05+00:00

The __omap_gem_get_pages() function is a wrapper around omap_gem_attach_pages() that returns the omap_obj->pages pointer through a function argument. Some callers don't need the pages pointer, and all of them can access omap_obj->pages directly. To simplify the code merge the __omap_gem_get_pages() wrapper with omap_gem_attach_pages() and update the callers accordingly. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen

drm/omap: gem: Rename GEM function with omap_gem_* prefix

2018-06-28T10:41:05+00:00

get_pages() as a local function name is too generic and easily confused for a generic MM kernel function. Rename it to __omap_gem_get_pages(). Rename the is_contiguous(), is_cache_coherent(), evict(), evict_entry(), fault_1d() and fault_2d() functions for the same reason. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen