kernel/linux.git/drivers/gpu/drm/drm_bridge.c, branch v6.1.168

drm/bridge: Fix improper bridge init order with pre_enable_prev_first

2024-06-12T09:03:21+00:00

[ Upstream commit e18aeeda0b6905c333df5a0566b99f5c84426098 ] For a given bridge pipeline if any bridge sets pre_enable_prev_first flag then the pre_enable for the previous bridge will be called before pre_enable of this bridge and opposite is done for post_disable. These are the potential bridge flags to alter bridge init order in order to satisfy the MIPI DSI host and downstream panel or bridge to function. However the existing pre_enable_prev_first logic with associated bridge ordering has broken for both pre_enable and post_disable calls. [pre_enable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flag on each iteration and assigned the previou bridge to limit pointer if the bridge doesn't enable pre_enable_prev_first flags. If control found Bridge 2 is pre_enable_prev_first then the iteration looks for Bridge 3 and found it is not pre_enable_prev_first and assigns it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3 and Bridge 2 and assign iter pointer with limit which is Bridge 4. Here is the actual problem, for the next iteration control look for Bridge 5 instead of Bridge 4 has iter pointer in previous iteration moved to Bridge 4 so this iteration skips the Bridge 4. The iteration found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned to Encoder. From next iteration Encoder skips as it is the last bridge for reverse order pipeline. So, the resulting pre_enable bridge order would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5. This patch fixes this by assigning limit to next pointer instead of previous bridge since the iteration always looks for bridge that does NOT request prev so assigning next makes sure the last bridge on a given iteration what exactly the limit bridge is. So, the resulting pre_enable bridge order with fix would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. [post_disable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example Bridge 5 and Bridge 4 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flags on each iteration and assigned the previou bridge to next and next to limit pointer if the bridge does enable pre_enable_prev_first flag. If control starts from Bridge 6 then it found next Bridge 5 is pre_enable_prev_first and immediately the next assigned to previous Bridge 6 and limit assignments to next Bridge 6 and call post_enable of Bridge 6 even though the next consecutive Bridge 5 is enabled with pre_enable_prev_first. This clearly misses the logic to find the state of next conducive bridge as everytime the next and limit assigns previous bridge if given bridge enabled pre_enable_prev_first. So, the resulting post_disable bridge order would be, - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1, Panel. This patch fixes this by assigning next with previou bridge only if the bridge doesn't enable pre_enable_prev_first flag and the next further assign it to limit. This way we can find the bridge that NOT requested prev to disable last. So, the resulting pre_enable bridge order with fix would be, - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1, Panel. Validated the bridge init ordering by incorporating dummy bridges in the sun6i-mipi-dsi pipeline Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") Signed-off-by: Jagan Teki Tested-by: Michael Trimarchi Reviewed-by: Dave Stevenson Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-1-jagan@amarulasolutions.com Signed-off-by: Sasha Levin

drm/bridge: Introduce pre_enable_prev_first to alter bridge init order

2023-07-19T14:21:23+00:00

[ Upstream commit 4fb912e5e19075874379cfcf074d90bd51ebf8ea ] DSI sink devices typically want the DSI host powered up and configured before they are powered up. pre_enable is the place this would normally happen, but they are called in reverse order from panel/connector towards the encoder, which is the "wrong" order. Add a new flag pre_enable_prev_first that any bridge can set to swap the order of pre_enable (and post_disable) for that and the immediately previous bridge. Should the immediately previous bridge also set the pre_enable_prev_first flag, the previous bridge to that will be called before either of those which requested pre_enable_prev_first. eg: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. Signed-off-by: Dave Stevenson Tested-by: Frieder Schrempf Reviewed-by: Frieder Schrempf Link: https://lore.kernel.org/r/20221205173328.1395350-5-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard Stable-dep-of: dd9e329af723 ("drm/bridge: ti-sn65dsi83: Fix enable/disable flow to meet spec") Signed-off-by: Sasha Levin

drm/bridge: Avoid uninitialized variable warning

2022-07-08T11:41:28+00:00

This code works, but technically it uses "num_in_bus_fmts" before it has been initialized so it leads to static checker warnings and probably KMEMsan warnings at run time. Initialize the variable to zero to silence the warning. Fixes: f32df58acc68 ("drm/bridge: Add the necessary bits to support bus format negotiation") Signed-off-by: Dan Carpenter Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/YrrIs3hoGcPVmXc5@kili

drm: Remove linux/media-bus-format.h from drm_crtc.h

2022-07-05T18:15:13+00:00

drm_crtc.h has no need for linux/media-bus-format.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/media-bus-format.h. Quite a few placs do currently depend on linux/media-bus-format.h without actually including it directly. All of those need to be fixed up. v2: Deal with ingenic as well v3: Fix up mxsfb and remaining parts of imx Acked-by: Sam Ravnborg Acked-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220630195114.17407-4-ville.syrjala@linux.intel.com

drm/bridge: Add devm_drm_bridge_add()

2022-06-02T22:15:10+00:00

This adds a devm managed version of drm_bridge_add(). Like other "devm" function listed in drm_bridge.h, this function takes an explicit "dev" to use for the lifetime management. A few notes: * In general we have a "struct device" for bridges that makes a good candidate for where the lifetime matches exactly what we want. * The "bridge->dev->dev" device appears to be the encoder device. That's not the right device to use for lifetime management. Suggested-by: Dmitry Baryshkov Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.3.Iba4b9bf6c7a1ee5ea2835ad7bd5eaf84d7688520@changeid

drm/bridge: Document the probe issue with MIPI-DSI bridges

2021-09-24T17:25:23+00:00

Interactions between bridges, panels, MIPI-DSI host and the component framework are not trivial and can lead to probing issues when implementing a display driver. Let's document the various cases we need too consider, and the solution to support all the cases. Signed-off-by: Maxime Ripard Reviewed-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20210910101218.1632297-3-maxime@cerno.tech

drm/bridge: Add documentation sections

2021-09-24T17:25:16+00:00

The bridge documentation overview is quite packed already, and we'll add some more documentation that isn't part of an overview at all. Let's add some sections to the documentation to separate each bits. Reviewed-by: Andrzej Hajda Reviewed-by: Sam Ravnborg Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210910101218.1632297-2-maxime@cerno.tech

drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c

2021-09-22T08:44:00+00:00

By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge() introduces a circular dependency between the modules drm (where devm_drm_of_get_bridge() ends up) and drm_kms_helper (where devm_drm_panel_bridge_add() is). Fix this by moving devm_drm_of_get_bridge() to bridge/panel.c and thus drm_kms_helper. Fixes: 87ea95808d53 ("drm/bridge: Add a function to abstract away panels") Reported-by: Stephen Rothwell Signed-off-by: Maxime Ripard Tested-by: Heiko Stuebner Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210917180925.2602266-1-maxime@cerno.tech

drm/bridge: Add a function to abstract away panels

2021-09-14T08:39:01+00:00

Display drivers so far need to have a lot of boilerplate to first retrieve either the panel or bridge that they are connected to using drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc functions or create a drm panel bridge through drm_panel_bridge_add. In order to reduce the boilerplate and hopefully create a path of least resistance towards using the DRM panel bridge layer, let's create the function devm_drm_of_get_bridge() to reduce that boilerplate. Signed-off-by: Maxime Ripard Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210910130941.1740182-2-maxime@cerno.tech

drm: Fix typo in comments

2021-08-02T08:19:43+00:00

fix typo for drm v1->v2: respin with the change "iff ==> implies that" Signed-off-by: Cai Huoqing Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com