Hi Maxime,
On Tue, Jul 20, 2021 at 7:15 PM Maxime Ripard maxime@cerno.tech wrote:
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.
Correct, but drm_of_find_panel_or_bridge is still required in some DSI drivers where the panel pointer required separately.
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_next to reduce that boilerplate.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/gpu/drm/drm_bridge.c | 62 +++++++++++++++++++++++++++++++++--- drivers/gpu/drm/drm_of.c | 3 ++ include/drm/drm_bridge.h | 2 ++ 3 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 044acd07c153..aef8c9f4fb9f 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -24,10 +24,12 @@ #include <linux/err.h> #include <linux/module.h> #include <linux/mutex.h> +#include <linux/of_graph.h>
#include <drm/drm_atomic_state_helper.h> #include <drm/drm_bridge.h> #include <drm/drm_encoder.h> +#include <drm/drm_panel.h>
#include "drm_crtc_internal.h"
@@ -50,10 +52,8 @@
- Display drivers are responsible for linking encoders with the first bridge
- in the chains. This is done by acquiring the appropriate bridge with
- of_drm_find_bridge() or drm_of_find_panel_or_bridge(), or creating it for a
- panel with drm_panel_bridge_add_typed() (or the managed version
- devm_drm_panel_bridge_add_typed()). Once acquired, the bridge shall be
- attached to the encoder with a call to drm_bridge_attach().
- drm_of_get_next(). Once acquired, the bridge shall be attached to the
- encoder with a call to drm_bridge_attach().
- Bridges are responsible for linking themselves with the next bridge in the
- chain, if any. This is done the same way as for encoders, with the call to
@@ -1223,6 +1223,60 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np) return NULL; } EXPORT_SYMBOL(of_drm_find_bridge);
+/**
- devm_drm_of_get_next - Return next bridge in the chain
- @dev: device to tie the bridge lifetime to
- @np: device tree node containing encoder output ports
- @port: port in the device tree node
- @endpoint: endpoint in the device tree node
- Given a DT node's port and endpoint number, finds the connected node
- and returns the associated bridge if any, or creates and returns a
- drm panel bridge instance if a panel is connected.
- Returns a pointer to the bridge if successful, or an error pointer
- otherwise.
- */
+struct drm_bridge *devm_drm_of_get_next(struct device *dev,
struct device_node *np,unsigned int port,unsigned int endpoint)+{
struct device_node *remote;struct drm_bridge *bridge;struct drm_panel *panel;/** of_graph_get_remote_node() produces a noisy error message if port* node isn't found and the absence of the port is a legit case here,* so at first we silently check whether graph presents in the* device-tree node.*/if (!of_graph_is_present(np))return ERR_PTR(-ENODEV);remote = of_graph_get_remote_node(np, port, endpoint);if (!remote)return ERR_PTR(-ENODEV);bridge = of_drm_find_bridge(remote);if (bridge) {of_node_put(remote);return bridge;}panel = of_drm_find_panel(remote);if (IS_ERR(panel)) {of_node_put(remote);return ERR_CAST(panel);}of_node_put(remote);return devm_drm_panel_bridge_add(dev, panel);+}
This is ideally similar to drm_of_find_panel_or_bridge followed by panel_bridge_add. Can we reuse drm_of_find_panel_or_bridge for now till it deprecated?
Thanks, Jagan.