linux-stable.git/drivers/gpu/drm/vc4, branch v5.7

drm/vc4: Fix HDMI mode validation

2020-03-27T12:38:47+00:00

Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.

Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.

Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.")
Reported-by: Stefan Wahren 
Suggested-by: Dave Stevenson 
Signed-off-by: Nicolas Saenz Julienne 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulienne@suse.de

drm/vc4/vc4_drv.h: Replace zero-length array with flexible-array member

2020-03-06T10:50:17+00:00

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20200305105707.GA19261@embeddedor

drm/vc4: Replace wait_for macros to remove use of msleep

2020-03-05T06:15:27+00:00

The wait_for macro's for Broadcom VC4 driver used msleep, which is
inappropriate due to its inaccuracy at low values (minimum wait time
is about 30ms on the Raspberry Pi).  This sleep was triggering in
v3d_clean_caches(), causing us to only be able to dispatch ~33 compute
jobs per second.

This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more accurate waits.

v2: Split from the v3d patch in case this tickles modesetting bugs (by
    anholt)

Signed-off-by: James Hughes 
Signed-off-by: Eric Anholt 
Link: https://patchwork.freedesktop.org/patch/msgid/20200217153145.13780-1-james.hughes@raspberrypi.com

drm/bridge: Extend bridge API to disable connector creation

2020-02-26T11:31:23+00:00

Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:

- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple components. For instance a
pipeline with a bridge connected to the DDC signals to read EDID data,
and another one connected to the HPD signal to detect connection and
disconnection, will not be possible to support through this model.

- It requires every bridge driver to implement similar connector
handling code, resulting in code duplication.

- It assumes that a bridge will either be wired to a connector or to
another bridge, but doesn't support bridges that can be used in both
positions very well (although there is some ad-hoc support for this in
the analogix_dp bridge driver).

In order to solve these issues, ownership of the connector should be
moved to the display controller driver (where it can be implemented
using helpers provided by the core).

Extend the bridge API to allow disabling connector creation in bridge
drivers as a first step towards the new model. The new flags argument to
the bridge .attach() operation allows instructing the bridge driver to
skip creating a connector. Unconditionally set the new flags argument to
0 for now to keep the existing behaviour, and modify all existing bridge
drivers to return an error when connector creation is not requested as
they don't support this feature yet.

The change is based on the following semantic patch, with manual review
and edits.

@ rule1 @
identifier funcs;
identifier fn;
@@
 struct drm_bridge_funcs funcs = {
 	...,
 	.attach = fn
 };

@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
statement S, S1;
@@
 int fn(
 	struct drm_bridge *bridge
+	, enum drm_bridge_attach_flags flags
 )
 {
 	... when != S
+	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+		DRM_ERROR("Fix bridge driver to make connector optional!");
+		return -EINVAL;
+	}
+
 	S1
 	...
 }

@ depends on rule1 @
identifier rule1.fn;
identifier bridge, flags;
expression E1, E2, E3;
@@
 int fn(
 	struct drm_bridge *bridge,
 	enum drm_bridge_attach_flags flags
 ) {
 <...
 drm_bridge_attach(E1, E2, E3
+	, flags
 )
 ...>
 }

@@
expression E1, E2, E3;
@@
 drm_bridge_attach(E1, E2, E3
+	, 0
 )

Signed-off-by: Laurent Pinchart 
Reviewed-by: Boris Brezillon 
Acked-by: Sam Ravnborg 
Reviewed-by: Tomi Valkeinen 
Tested-by: Sebastian Reichel 
Reviewed-by: Sebastian Reichel 
Acked-by: Daniel Vetter 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com

drm/vc4: Convert to CRTC VBLANK callbacks

2020-02-13T12:10:10+00:00

VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert vc4 over.

Signed-off-by: Thomas Zimmermann 
Acked-by: Eric Anholt 
Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-19-tzimmermann@suse.de

drm/vc4: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

2020-02-13T12:10:10+00:00

The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert vc4
over.

Signed-off-by: Thomas Zimmermann 
Acked-by: Eric Anholt 
Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-18-tzimmermann@suse.de

drm/vc4: plane_state->fb iff plane_state->crtc

2020-01-28T14:42:43+00:00

Checking both is one too much, so wrap a WARN_ON around it to stope
the copypasta.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20191213172612.1514842-7-daniel.vetter@ffwll.ch

drm/vc4: dsi: Fix bridge chain handling

2020-01-08T08:09:48+00:00

Commit 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked
list") patched the bridge chain logic to use a double-linked list instead
of a single-linked list. This change induced changes to the VC4 driver
which was manually resetting the encoder->bridge element to NULL to
control the enable/disable sequence of the bridge chain. During this
conversion, 2 bugs were introduced:

1/ list_splice() was used to move chain elements to our own internal
   chain, but list_splice() does not reset the source list to an empty
   state, leading to unexpected bridge hook calls when
   drm_bridge_chain_xxx() helpers were called by the core. Replacing
   those list_splice() calls by list_splice_init() ones fixes this
   problem.

2/ drm_bridge_chain_xxx() helpers operate on the
   bridge->encoder->bridge_chain list, which is now empty. When the
   helper uses list_for_each_entry_reverse() we end up with no operation
   done which is not what we want. But that's even worse when the helper
   uses list_for_each_entry_from(), because in that case we end up in
   an infinite loop searching for the list head element which is no
   longer encoder->bridge_chain but vc4_dsi->bridge_chain. To address
   that problem we stop using the bridge chain helpers and call the
   hooks directly.

Reported-by: Marek Szyprowski 
Cc: Eric Anholt 
Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list")
Signed-off-by: Boris Brezillon 
Reviewed-by: Andrzej Hajda 
Acked-by: Eric Anholt 
Link: https://patchwork.freedesktop.org/patch/msgid/20191227144124.210294-2-boris.brezillon@collabora.com

drm/vc4: Provide ddc symlink in connector sysfs directory

2020-01-07T19:25:43+00:00

Use the ddc pointer provided by the generic connector.

Signed-off-by: Andrzej Pietrasiewicz 
Acked-by: Sam Ravnborg 
Reviewed-by: Emil Velikov 
Link: https://patchwork.freedesktop.org/patch/msgid/20200102132300.24309-3-andrzej.p@collabora.com

drm/vc4: Use dma_resv locking wrappers

2019-12-17T16:26:08+00:00

I'll add more fancy logic to them soon, so everyone really has to use
them. Plus they already provide some nice additional debug
infrastructure on top of direct ww_mutex usage for the fences tracked
by dma_resv.

Reviewed-by: Eric Anholt 
Cc: Eric Anholt 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20191125094356.161941-5-daniel.vetter@ffwll.ch