wireguard-linux/drivers/gpu/drm/rcar-du, branch jd/unified-crypt-queue

drm/bridge: Extend bridge API to disable connector creation

2020-02-26T11:31:23Z

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/bridge: Patch atomic hooks to take a drm_bridge_state

2020-01-31T15:00:24Z

This way the drm_bridge_funcs interface is consistent with the rest of the subsystem. The drivers implementing those hooks are patched too. v10: * Add changelog to the commit message v8 -> v9: * No changes v7: * Adjust things to the bridge_state changes v6: * Also fixed rcar-du/rcar_lvds.c same as analogix/analogix_dp_core.c v5: * No changes v4: * Rename func params into old_bridge_state * Add Laurent's Rb v3: * Old state clarification moved to a separate patch v2: * Pass the old bridge state Signed-off-by: Boris Brezillon Reviewed-by: Laurent Pinchart Signed-off-by: Neil Armstrong [narmstrong: renamed state as old_bridge_state in rcar_lvds_atomic_disable] Reviewed by: Jernej Skrabec Tested-by: Jonas Karlman Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-5-boris.brezillon@collabora.com

drm/rcar-du: Plug atomic state hooks to the default implementation

2020-01-31T15:00:23Z

This is needed to pass a bridge state to all atomic hooks, if we don't do that, the core can't duplicate/create bridge states. v10: * Add changelog to the commit message v9: * Add Neil's R-b * Move earlier in the series v8: * No changes v7: * New patch Signed-off-by: Boris Brezillon Reviewed-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-3-boris.brezillon@collabora.com

Revert "drm/bridge: Patch atomic hooks to take a drm_bridge_state"

2020-01-07T23:34:28Z

This reverts commit f7619a58ef92 ("drm/bridge: Patch atomic hooks to take a drm_bridge_state"). Commit 6ed7e9625fa6 ("drm/bridge: Add a drm_bridge_state object") introduced a circular dependency between drm.ko and drm_kms_helper.ko which uncovered a misdesign in how the whole thing was implemented. Let's revert all patches depending on the bridge_state infrastructure for now. Signed-off-by: Boris Brezillon Acked-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20200107185807.606999-5-boris.brezillon@collabora.com

drm/bridge: Patch atomic hooks to take a drm_bridge_state

2020-01-07T09:10:59Z

This way the drm_bridge_funcs interface is consistent with the rest of the subsystem. The only driver implementing those hooks (analogix DP) is patched too. Signed-off-by: Boris Brezillon Reviewed-by: Laurent Pinchart Signed-off-by: Neil Armstrong Reviewed by: Jernej Skrabec Tested-by: Jonas Karlman [narmstrong: renamed state as old_bridge_state in rcar_lvds_atomic_disable] Link: https://patchwork.freedesktop.org/patch/msgid/20200106143409.32321-3-narmstrong@baylibre.com

Merge tag 'du-next-20191218' of git://linuxtv.org/pinchartl/media into drm-next

2019-12-18T15:19:26Z

R-Car Display Unit changes: - Color Management Module support - LVDS encoder dual-link support enhancements - R8A77980 support Signed-off-by: Daniel Vetter From: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20191218151710.GA13830@pendragon.ideasonboard.com

drm: rcar-du: Add r8a77980 support

2019-12-18T00:40:29Z

Add direct support for the r8a77980 (V3H). The V3H shares a common, compatible configuration with the r8a77970 (V3M) so that device info structure is reused. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart

drm: rcar-du: lvds: Allow for even and odd pixels swap

2019-12-18T00:40:26Z

DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels can be used to work out if the driver needs to swap even and odd pixels around. This patch makes use of the return value from function drm_of_lvds_get_dual_link_pixel_order to determine if we need to swap odd and even pixels around for things to work properly. The dual_link boolean field from struct rcar_lvds is not sufficient to describe the type of LVDS link anymore, since we now have information related to pixel order, therefore rename it to link_type and repurpose its usage to fit the new requirements. Signed-off-by: Fabrizio Castro Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart

drm: rcar-du: lvds: Get dual link configuration from DT

2019-12-18T00:40:23Z

For dual-LVDS configurations, it is now possible to mark the DT port nodes for the sink with boolean properties (like dual-lvds-even-pixels and dual-lvds-odd-pixels) to let drivers know the encoders need to be configured in dual-LVDS mode. Rework the implementation of rcar_lvds_parse_dt_companion to make use of the DT markers while keeping backward compatibility. Signed-off-by: Fabrizio Castro Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart

drm: rcar-du: lvds: Improve identification of panels

2019-12-18T00:40:19Z

Dual-LVDS panels are mistakenly identified as bridges, this commit replaces the current logic with a call to drm_of_find_panel_or_bridge to sort that out. Signed-off-by: Fabrizio Castro Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart