linux-toradex.git/drivers/gpu/drm/omapdrm, branch v4.20

drm/omap: fix incorrect union usage

2018-12-03T12:46:30+00:00

The DSI encoder sets dssdev->ops->dsi.set_config, which is stored at the
same offset as dssdev->ops->hdmi.set_hdmi_mode. The code in omap_encoder
only checks if dssdev->ops->hdmi.set_hdmi_mode is NULL. Due to the way
union works, it won't be NULL if dsi.set_config is set. This means
dsi_set_config will be called with config=hdmi_mode=false=NULL parameter
resulting in a NULL dereference. Also the dereference happens while
console is locked, so kernel hangs without any debug output without
"fb.lockless_register_fb=1" parameter.

This restructures the code, so that the HDMI mode is only configured
for HDMI output types.

Fixes: 83910ad3f51fb ("drm/omap: Move most omap_dss_driver operations to omap_dss_device_ops")
Signed-off-by: Sebastian Reichel 
Tested-by: Tony Lindgren 
[tomi.valkeinen@ti.com: dropped the safeguard]
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20181121160916.22017-5-sebastian.reichel@collabora.com

drm/omap: populate DSI platform bus earlier

2018-12-03T12:46:30+00:00

After the changes from 4.20 the DSI encoder tries to find the
attached panel before populating the DSI bus. If the panel is
not found -EPROBE_DEFER is returned, so the DSI bus is never
populated and the panel never added.

Fix this by populating the DSI bus before searching for the
video sink in dsi_init_output().

Fixes: 27d624527d992 ("drm/omap: dss: Acquire next dssdev at probe time")
Acked-by: Pavel Machek 
Tested-by: Tony Lindgren 
Tested-by: Pavel Machek 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20181121160916.22017-3-sebastian.reichel@collabora.com

drm/omap: fix bus_flags for panel-dpi

2018-12-03T12:36:05+00:00

panel-dpi used to convey the bus-flags via the videomode, but recent
changes changed the use of videomode to DRM's drm_display_mode which
does not contain bus-flags. This broke panel-dpi, which didn't
explicitly store the bus-flags into dssdev->bus_flags.

Fix this by setting dssdev->bus_flags. Also change the bus_flags type to
u32, as that is the type used in the DRM framework, and we would get a
warning with drm_bus_flags_from_videomode() otherwise.

Fixes: 3fbda31e814868d8477ddf52d74b7b8f596578e8 ("drm/omap: Split mode fixup and mode set from encoder enable")
Signed-off-by: Tomi Valkeinen 
Reported-by: H. Nikolaus Schaller 
Link: https://patchwork.freedesktop.org/patch/msgid/20181126092447.11864-1-tomi.valkeinen@ti.com
Reviewed-by: Laurent Pinchart

drm/omap: dsi: Fix missing of_platform_depopulate()

2018-11-12T09:50:13+00:00

We're missing a call to of_platform_depopulate() on errors for dsi.
Looks like dss is already doing this.

Signed-off-by: Tony Lindgren 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20181106152802.38599-1-tony@atomide.com

drm/omap: Move DISPC runtime PM handling to omapdrm

2018-11-12T09:50:13+00:00

The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers
attempt to manage the runtime PM state of the connected DISPC, based on
the rationale that the DISPC providing data to the encoders requires
ensuring that the display is active whenever the encoders are active.

While the DISPC provides data to the encoders, it doesn't as such
constitute a resource that encoders require in order to be taken out
of suspend, contrary to for instance a functional clock or a power
supply. Encoders registers can be accessed without the DISPC being
active, and while the encoders will not output any video stream without
being fed by the DISPC, the DISPC PM state doesn't influence the
encoders PM state.

For this reason the DISPC PM state is better managed from the omapdrm
driver, in the CRTC enable and disable operations. This allows the
encoders PM state to be handled separately from the DISPC, and in
particular at times when the DISPC may not be available (for instance at
probe due to the DSS probe being deferred, or at remove time du to the
DISPC being already removed).

Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-5-laurent.pinchart@ideasonboard.com

drm/omap: dsi: Ensure the device is active during probe

2018-11-12T09:50:13+00:00

The probe function performs hardware access to read the number of
supported data lanes from a configuration register and thus requires the
device to be active. Ensure this by surrounding the access with
dsi_runtime_get() and dsi_runtime_put() calls.

Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: Laurent Pinchart 
Acked-by: Tony Lindgren 
Reviewed-by: Sebastian Reichel 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-4-laurent.pinchart@ideasonboard.com

drm/omap: hdmi4: Ensure the device is active during bind

2018-11-12T09:50:13+00:00

The bind function performs hardware access (in hdmi4_cec_init()) and
thus requires the device to be active. Ensure this by surrounding the
bind function by hdmi_runtime_get() and hdmi_runtime_put() calls.

Fixes: 27d624527d99 ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-3-laurent.pinchart@ideasonboard.com

drm/omap: Populate DSS children in omapdss driver

2018-11-12T09:50:13+00:00

The DSS DT node contains children that describe the DSS components
(DISPC and internal encoders). Each of those components is handled by a
platform driver, and thus needs to be backed by a platform device.

The corresponding platform devices are created in mach-omap2 code by a
call to of_platform_populate(). While this approach has worked so far,
it doesn't model the hardware architecture very well, as it creates
child devices before the parent is ready to handle them. This would be
akin to creating I2C slaves before the I2C master is available.

The task can be easily performed in the omapdss driver code instead,
simplifying mach-omap2 code. We however can't remove the mach-omap2 code
completely as the omap2fb driver still depends on it, but we can move it
to the omap2fb-specific section, where it can stay until the omap2fb
driver gets removed.

This has the added benefit of not allowing DSS components to probe
before the DSS itself, which led to runtime PM issues when the DSS probe
is deferred.

Fixes: 27d624527d99 ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: Laurent Pinchart 
Acked-by: Tony Lindgren 
Reviewed-by: Sebastian Reichel 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-2-laurent.pinchart@ideasonboard.com

drm/omap: fix use of freed memory

2018-10-02T06:36:56+00:00

omap_connector_destroy() does:

kfree(omap_connector);
omapdss_device_put(omap_connector->output);
omapdss_device_put(omap_connector->display);

Fix this by moving the kfree after the omapdss_device_puts.

This bug was introduced in 949ea2ef3fed4e1d0f9b80ec21ed81a9833ac248

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart

drm/omap: Replace drm_dev_unref with drm_dev_put

2018-10-02T06:36:56+00:00

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
Signed-off-by: Tomi Valkeinen