linux-toradex.git/drivers/gpu/drm/vc4/vc4_plane.c, branch v4.14-rc4

drm: Plumb modifiers through plane init

2017-08-01T16:50:06+00:00

This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.

This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.

v2: A minor addition from Daniel

v3:
* Updated commit message
* s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
* Remove some excess newlines (Liviu)
* Update comment for > 64 modifiers (Liviu)

v4: Minor comment adjustments (Liviu)

v5: Some new platforms added due to rebase

v6: Add some missed plane inits (or maybe they're new - who knows at
this point) (Daniel)

Signed-off-by: Ben Widawsky 
Reviewed-by: Daniel Stone  (v2)
Reviewed-by: Liviu Dudau 
Signed-off-by: Daniel Stone

drm/vc4: Hook up plane prepare_fb to lookup dma-buf reservations.

2017-06-22T18:13:54+00:00

This way drm_atomic_helper_wait_for_fences() will actually do
something.  The vc4_seqno_cb has been doing the fence waits on V3D
manually, so far.

Signed-off-by: Eric Anholt 
Link: http://patchwork.freedesktop.org/patch/msgid/20170621185002.28563-1-eric@anholt.net
Acked-by: Daniel Vetter 
Reviewed-by: Boris Brezillon

drm/vc4: Add T-format scanout support.

2017-06-15T23:02:45+00:00

The T tiling format is what V3D uses for textures, with no raster
support at all until later revisions of the hardware (and always at a
large 3D performance penalty).  If we can't scan out V3D's format,
then we often need to do a relayout at some stage of the pipeline,
either right before texturing from the scanout buffer (common in X11
without a compositor) or between a tiled screen buffer right before
scanout (an option I've considered in trying to resolve this
inconsistency, but which means needing to use the dirty fb ioctl and
having some update policy).

T-format scanout lets us avoid either of those shadow copies, for a
massive, obvious performance improvement to X11 window dragging
without a compositor.  Unfortunately, enabling a compositor to work
around the discrepancy has turned out to be too costly in memory
consumption for the Raspbian distribution.

Because the HVS operates a scanline at a time, compositing from T does
increase the memory bandwidth cost of scanout.  On my 1920x1080@32bpp
display on a RPi3, we go from about 15% of system memory bandwidth
with linear to about 20% with tiled.  However, for X11 this still ends
up being a huge performance win in active usage.

This patch doesn't yet handle src_x/src_y offsetting within the tiled
buffer.  However, we fail to do so for untiled buffers already.

Signed-off-by: Eric Anholt 
Link: http://patchwork.freedesktop.org/patch/msgid/20170608001336.12842-1-eric@anholt.net
Reviewed-by: Boris Brezillon

drm/vc4: fix include notation and remove -Iinclude/drm flag

2017-05-22T07:36:01+00:00

Include  instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.

While we are here, use <...> instead of "..." for include/linux/*.h
and include/sound/*.h headers too.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1495081793-9707-2-git-send-email-yamada.masahiro@socionext.com

drm: Add acquire ctx parameter to ->update_plane

2017-03-29T07:14:01+00:00

Just rolling it out, no code change here.

Cc: Ben Skeggs 
Cc: Russell King 
Cc: Rob Clark 
Cc: Laurent Pinchart 
Cc: Eric Anholt 
Reviewed-by: Harry Wentland 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-3-daniel.vetter@ffwll.ch

drm: vc4: remove redundant check of plane being non-null

2017-03-17T23:44:14+00:00

The pointer plane is always null on the error path at label 'fail'
hence the check if it is non-null is redundant. We can therefore
remove the check and the destruction of plane as well as the fail
error path and instead just return an -ENOMEM ERR_PTR.

Detected by CoverityScan, CID#1339532 ("Logically Dead Code")

Signed-off-by: Colin Ian King 
Reviewed-by: Eric Anholt 
Link: http://patchwork.freedesktop.org/patch/msgid/20170316185418.32765-1-colin.king@canonical.com

drm/vc4: Don't wait for vblank when updating the cursor

2017-02-28T20:49:40+00:00

Commonly used desktop environments such as xfce4 and gnome
on debian sid can flood the graphics drivers with cursor
updates.  Because the current implementation is waiting
for a vblank between cursor updates, this will cause the
display to hang for a long time since a typical refresh
rate is only 60Hz.

This is unnecessary and unexpected by user mode software,
so simply swap out the cursor frame buffer without waiting.

Signed-off-by: Michael Zoran 
Reviewed-by: Eric Anholt 
Link: http://patchwork.freedesktop.org/patch/msgid/20170224015431.24583-1-mzoran@crowfest.net

Merge tag 'v4.10-rc8' into drm-next

2017-02-23T02:10:12+00:00

Linux 4.10-rc8

Backmerge Linus rc8 to fix some conflicts, but also
to avoid pulling it in via a fixes pull from someone.

drm: vc4: adapt to new behaviour of drm_crtc.c

2017-02-08T22:19:23+00:00

When drm_crtc_init_with_planes() was orignally added
(in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
being non-null. If that was the case, it modified primary->possible_crtcs.

Then, when support for cursor planes was added
(fc1d3e44ef7c1db93384150fdbf8948dcf949f15 drm: Allow drivers to register
cursor planes with crtc), the same behaviour was implemented for cursor
planes.

vc4_plane_init() since its inception has passed 0xff as "possible_crtcs"
parameter to drm_universal_plane_init(). With a change in drm_crtc.c
(7abc7d47510c75dd984380ebf819616e574c9604 drm: don't override
possible_crtcs for primary/cursor planes) passing 0xff results in primary's
possible_crtcs set to 0xff (cursor was updated manually by vc4_crtc.c).
Consequently, it would be allowed to use the primary plane from CRTC 1 (for
example) on CRTC 0, which would result in the overlay and cursors being
buried.

Signed-off-by: Andrzej Pietrasiewicz 
Reviewed-by: Eric Anholt 
Link: http://patchwork.freedesktop.org/patch/msgid/1485941708-27892-1-git-send-email-andrzej.p@samsung.com
Fixes: 7abc7d47510c ("drm: don't override possible_crtcs for primary/cursor planes")

drm: Improve drm_mm search (and fix topdown allocation) with rbtrees

2017-02-03T10:10:32+00:00

The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.

In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.

v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: Lucas Stach 
Cc: Christian Gmeiner 
Cc: Rob Clark 
Cc: Thierry Reding 
Cc: Stephen Warren 
Cc: Alexandre Courbot 
Cc: Eric Anholt 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Reviewed-by: Alex Deucher 
Reviewed-by: Sinclair Yeh  # vmwgfx
Reviewed-by: Lucas Stach  #etnaviv
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170202210438.28702-1-chris@chris-wilson.co.uk