2015-01-21 00:38:44 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2014 Samsung Electronics Co., Ltd
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sub license,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial portions
|
|
|
|
* of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
* DEALINGS IN THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/module.h>
|
2016-09-01 00:09:05 +08:00
|
|
|
#include <linux/mutex.h>
|
2015-01-21 00:38:44 +08:00
|
|
|
|
2020-01-28 21:55:03 +08:00
|
|
|
#include <drm/drm_atomic_state_helper.h>
|
2016-09-01 00:09:05 +08:00
|
|
|
#include <drm/drm_bridge.h>
|
2016-11-28 23:59:08 +08:00
|
|
|
#include <drm/drm_encoder.h>
|
2021-09-10 21:09:39 +08:00
|
|
|
#include <drm/drm_of.h>
|
2021-03-24 05:50:08 +08:00
|
|
|
#include <drm/drm_print.h>
|
2015-01-21 00:38:44 +08:00
|
|
|
|
2016-11-29 00:32:05 +08:00
|
|
|
#include "drm_crtc_internal.h"
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* DOC: overview
|
|
|
|
*
|
2016-12-30 04:48:26 +08:00
|
|
|
* &struct drm_bridge represents a device that hangs on to an encoder. These are
|
2015-12-04 16:45:47 +08:00
|
|
|
* handy when a regular &drm_encoder entity isn't enough to represent the entire
|
2015-05-21 13:33:17 +08:00
|
|
|
* encoder chain.
|
|
|
|
*
|
2015-12-04 16:45:47 +08:00
|
|
|
* A bridge is always attached to a single &drm_encoder at a time, but can be
|
2020-02-26 19:24:26 +08:00
|
|
|
* either connected to it directly, or through a chain of bridges::
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2020-02-26 19:24:26 +08:00
|
|
|
* [ CRTC ---> ] Encoder ---> Bridge A ---> Bridge B
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2020-02-26 19:24:26 +08:00
|
|
|
* Here, the output of the encoder feeds to bridge A, and that furthers feeds to
|
|
|
|
* bridge B. Bridge chains can be arbitrarily long, and shall be fully linear:
|
|
|
|
* Chaining multiple bridges to the output of a bridge, or the same bridge to
|
|
|
|
* the output of different bridges, is not supported.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2021-09-10 18:11:55 +08:00
|
|
|
* &drm_bridge, like &drm_panel, aren't &drm_mode_object entities like planes,
|
|
|
|
* CRTCs, encoders or connectors and hence are not visible to userspace. They
|
|
|
|
* just provide additional hooks to get the desired output at the end of the
|
|
|
|
* encoder chain.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* DOC: display driver integration
|
|
|
|
*
|
2020-02-26 19:24:26 +08:00
|
|
|
* Display drivers are responsible for linking encoders with the first bridge
|
|
|
|
* in the chains. This is done by acquiring the appropriate bridge with
|
2021-09-10 21:09:39 +08:00
|
|
|
* devm_drm_of_get_bridge(). Once acquired, the bridge shall be attached to the
|
|
|
|
* encoder with a call to drm_bridge_attach().
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2020-02-26 19:24:26 +08:00
|
|
|
* 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
|
|
|
|
* drm_bridge_attach() occurring in the &drm_bridge_funcs.attach operation.
|
|
|
|
*
|
|
|
|
* Once these links are created, the bridges can participate along with encoder
|
|
|
|
* functions to perform mode validation and fixup (through
|
|
|
|
* drm_bridge_chain_mode_valid() and drm_atomic_bridge_chain_check()), mode
|
|
|
|
* setting (through drm_bridge_chain_mode_set()), enable (through
|
|
|
|
* drm_atomic_bridge_chain_pre_enable() and drm_atomic_bridge_chain_enable())
|
|
|
|
* and disable (through drm_atomic_bridge_chain_disable() and
|
|
|
|
* drm_atomic_bridge_chain_post_disable()). Those functions call the
|
|
|
|
* corresponding operations provided in &drm_bridge_funcs in sequence for all
|
|
|
|
* bridges in the chain.
|
|
|
|
*
|
|
|
|
* For display drivers that use the atomic helpers
|
|
|
|
* drm_atomic_helper_check_modeset(),
|
|
|
|
* drm_atomic_helper_commit_modeset_enables() and
|
|
|
|
* drm_atomic_helper_commit_modeset_disables() (either directly in hand-rolled
|
|
|
|
* commit check and commit tail handlers, or through the higher-level
|
|
|
|
* drm_atomic_helper_check() and drm_atomic_helper_commit_tail() or
|
|
|
|
* drm_atomic_helper_commit_tail_rpm() helpers), this is done transparently and
|
|
|
|
* requires no intervention from the driver. For other drivers, the relevant
|
|
|
|
* DRM bridge chain functions shall be called manually.
|
|
|
|
*
|
2020-02-26 19:24:40 +08:00
|
|
|
* Bridges also participate in implementing the &drm_connector at the end of
|
|
|
|
* the bridge chain. Display drivers may use the drm_bridge_connector_init()
|
|
|
|
* helper to create the &drm_connector, or implement it manually on top of the
|
|
|
|
* connector-related operations exposed by the bridge (see the overview
|
|
|
|
* documentation of bridge operations for more details).
|
2015-05-21 13:33:17 +08:00
|
|
|
*/
|
|
|
|
|
2021-09-10 18:11:56 +08:00
|
|
|
/**
|
|
|
|
* DOC: special care dsi
|
|
|
|
*
|
|
|
|
* The interaction between the bridges and other frameworks involved in
|
|
|
|
* the probing of the upstream driver and the bridge driver can be
|
|
|
|
* challenging. Indeed, there's multiple cases that needs to be
|
|
|
|
* considered:
|
|
|
|
*
|
|
|
|
* - The upstream driver doesn't use the component framework and isn't a
|
|
|
|
* MIPI-DSI host. In this case, the bridge driver will probe at some
|
|
|
|
* point and the upstream driver should try to probe again by returning
|
|
|
|
* EPROBE_DEFER as long as the bridge driver hasn't probed.
|
|
|
|
*
|
|
|
|
* - The upstream driver doesn't use the component framework, but is a
|
|
|
|
* MIPI-DSI host. The bridge device uses the MIPI-DCS commands to be
|
|
|
|
* controlled. In this case, the bridge device is a child of the
|
|
|
|
* display device and when it will probe it's assured that the display
|
|
|
|
* device (and MIPI-DSI host) is present. The upstream driver will be
|
|
|
|
* assured that the bridge driver is connected between the
|
|
|
|
* &mipi_dsi_host_ops.attach and &mipi_dsi_host_ops.detach operations.
|
|
|
|
* Therefore, it must run mipi_dsi_host_register() in its probe
|
|
|
|
* function, and then run drm_bridge_attach() in its
|
|
|
|
* &mipi_dsi_host_ops.attach hook.
|
|
|
|
*
|
|
|
|
* - The upstream driver uses the component framework and is a MIPI-DSI
|
|
|
|
* host. The bridge device uses the MIPI-DCS commands to be
|
|
|
|
* controlled. This is the same situation than above, and can run
|
|
|
|
* mipi_dsi_host_register() in either its probe or bind hooks.
|
|
|
|
*
|
|
|
|
* - The upstream driver uses the component framework and is a MIPI-DSI
|
|
|
|
* host. The bridge device uses a separate bus (such as I2C) to be
|
|
|
|
* controlled. In this case, there's no correlation between the probe
|
|
|
|
* of the bridge and upstream drivers, so care must be taken to avoid
|
|
|
|
* an endless EPROBE_DEFER loop, with each driver waiting for the
|
|
|
|
* other to probe.
|
|
|
|
*
|
|
|
|
* The ideal pattern to cover the last item (and all the others in the
|
|
|
|
* MIPI-DSI host driver case) is to split the operations like this:
|
|
|
|
*
|
|
|
|
* - The MIPI-DSI host driver must run mipi_dsi_host_register() in its
|
|
|
|
* probe hook. It will make sure that the MIPI-DSI host sticks around,
|
|
|
|
* and that the driver's bind can be called.
|
|
|
|
*
|
|
|
|
* - In its probe hook, the bridge driver must try to find its MIPI-DSI
|
|
|
|
* host, register as a MIPI-DSI device and attach the MIPI-DSI device
|
|
|
|
* to its host. The bridge driver is now functional.
|
|
|
|
*
|
|
|
|
* - In its &struct mipi_dsi_host_ops.attach hook, the MIPI-DSI host can
|
|
|
|
* now add its component. Its bind hook will now be called and since
|
|
|
|
* the bridge driver is attached and registered, we can now look for
|
|
|
|
* and attach it.
|
|
|
|
*
|
|
|
|
* At this point, we're now certain that both the upstream driver and
|
|
|
|
* the bridge driver are functional and we can't have a deadlock-like
|
|
|
|
* situation when probing.
|
|
|
|
*/
|
|
|
|
|
2015-01-21 00:38:44 +08:00
|
|
|
static DEFINE_MUTEX(bridge_lock);
|
|
|
|
static LIST_HEAD(bridge_list);
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_add - add the given bridge to the global bridge list
|
|
|
|
*
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
*/
|
2017-07-03 16:42:17 +08:00
|
|
|
void drm_bridge_add(struct drm_bridge *bridge)
|
2015-01-21 00:38:44 +08:00
|
|
|
{
|
2020-02-26 19:24:27 +08:00
|
|
|
mutex_init(&bridge->hpd_mutex);
|
|
|
|
|
2015-01-21 00:38:44 +08:00
|
|
|
mutex_lock(&bridge_lock);
|
|
|
|
list_add_tail(&bridge->list, &bridge_list);
|
|
|
|
mutex_unlock(&bridge_lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_add);
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_remove - remove the given bridge from the global bridge list
|
|
|
|
*
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
*/
|
2015-01-21 00:38:44 +08:00
|
|
|
void drm_bridge_remove(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
mutex_lock(&bridge_lock);
|
|
|
|
list_del_init(&bridge->list);
|
|
|
|
mutex_unlock(&bridge_lock);
|
2020-02-26 19:24:27 +08:00
|
|
|
|
|
|
|
mutex_destroy(&bridge->hpd_mutex);
|
2015-01-21 00:38:44 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_remove);
|
|
|
|
|
2020-01-28 21:55:03 +08:00
|
|
|
static struct drm_private_state *
|
|
|
|
drm_bridge_atomic_duplicate_priv_state(struct drm_private_obj *obj)
|
|
|
|
{
|
|
|
|
struct drm_bridge *bridge = drm_priv_to_bridge(obj);
|
|
|
|
struct drm_bridge_state *state;
|
|
|
|
|
|
|
|
state = bridge->funcs->atomic_duplicate_state(bridge);
|
|
|
|
return state ? &state->base : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
drm_bridge_atomic_destroy_priv_state(struct drm_private_obj *obj,
|
|
|
|
struct drm_private_state *s)
|
|
|
|
{
|
|
|
|
struct drm_bridge_state *state = drm_priv_to_bridge_state(s);
|
|
|
|
struct drm_bridge *bridge = drm_priv_to_bridge(obj);
|
|
|
|
|
|
|
|
bridge->funcs->atomic_destroy_state(bridge, state);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct drm_private_state_funcs drm_bridge_priv_state_funcs = {
|
|
|
|
.atomic_duplicate_state = drm_bridge_atomic_duplicate_priv_state,
|
|
|
|
.atomic_destroy_state = drm_bridge_atomic_destroy_priv_state,
|
|
|
|
};
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
2016-11-28 23:59:08 +08:00
|
|
|
* drm_bridge_attach - attach the bridge to an encoder's chain
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2016-11-28 23:59:08 +08:00
|
|
|
* @encoder: DRM encoder
|
|
|
|
* @bridge: bridge to attach
|
|
|
|
* @previous: previous bridge in the chain (optional)
|
drm/bridge: Extend bridge API to disable connector creation
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 <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
2020-02-26 19:24:29 +08:00
|
|
|
* @flags: DRM_BRIDGE_ATTACH_* flags
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2016-11-28 23:59:08 +08:00
|
|
|
* Called by a kms driver to link the bridge to an encoder's chain. The previous
|
|
|
|
* argument specifies the previous bridge in the chain. If NULL, the bridge is
|
|
|
|
* linked directly at the encoder's output. Otherwise it is linked at the
|
|
|
|
* previous bridge's output.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2016-11-28 23:59:08 +08:00
|
|
|
* If non-NULL the previous bridge must be already attached by a call to this
|
|
|
|
* function.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2018-08-06 14:19:10 +08:00
|
|
|
* Note that bridges attached to encoders are auto-detached during encoder
|
|
|
|
* cleanup in drm_encoder_cleanup(), so drm_bridge_attach() should generally
|
|
|
|
* *not* be balanced with a drm_bridge_detach() in driver code.
|
|
|
|
*
|
2015-05-21 13:33:17 +08:00
|
|
|
* RETURNS:
|
|
|
|
* Zero on success, error code on failure
|
|
|
|
*/
|
2016-11-28 23:59:08 +08:00
|
|
|
int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
|
drm/bridge: Extend bridge API to disable connector creation
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 <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
2020-02-26 19:24:29 +08:00
|
|
|
struct drm_bridge *previous,
|
|
|
|
enum drm_bridge_attach_flags flags)
|
2015-01-21 00:38:44 +08:00
|
|
|
{
|
2016-11-28 23:59:08 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!encoder || !bridge)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (previous && (!previous->dev || previous->encoder != encoder))
|
2015-01-21 00:38:44 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (bridge->dev)
|
|
|
|
return -EBUSY;
|
|
|
|
|
2016-11-28 23:59:08 +08:00
|
|
|
bridge->dev = encoder->dev;
|
|
|
|
bridge->encoder = encoder;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
if (previous)
|
|
|
|
list_add(&bridge->chain_node, &previous->chain_node);
|
|
|
|
else
|
|
|
|
list_add(&bridge->chain_node, &encoder->bridge_chain);
|
|
|
|
|
2016-11-28 23:59:08 +08:00
|
|
|
if (bridge->funcs->attach) {
|
drm/bridge: Extend bridge API to disable connector creation
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 <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
2020-02-26 19:24:29 +08:00
|
|
|
ret = bridge->funcs->attach(bridge, flags);
|
2020-01-28 21:55:03 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto err_reset_bridge;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bridge->funcs->atomic_reset) {
|
|
|
|
struct drm_bridge_state *state;
|
|
|
|
|
|
|
|
state = bridge->funcs->atomic_reset(bridge);
|
|
|
|
if (IS_ERR(state)) {
|
|
|
|
ret = PTR_ERR(state);
|
|
|
|
goto err_detach_bridge;
|
2020-01-08 02:58:07 +08:00
|
|
|
}
|
2020-01-28 21:55:03 +08:00
|
|
|
|
|
|
|
drm_atomic_private_obj_init(bridge->dev, &bridge->base,
|
|
|
|
&state->base,
|
|
|
|
&drm_bridge_priv_state_funcs);
|
2020-01-06 22:34:06 +08:00
|
|
|
}
|
|
|
|
|
2015-01-21 00:38:44 +08:00
|
|
|
return 0;
|
2020-01-28 21:55:03 +08:00
|
|
|
|
|
|
|
err_detach_bridge:
|
|
|
|
if (bridge->funcs->detach)
|
|
|
|
bridge->funcs->detach(bridge);
|
|
|
|
|
|
|
|
err_reset_bridge:
|
|
|
|
bridge->dev = NULL;
|
|
|
|
bridge->encoder = NULL;
|
|
|
|
list_del(&bridge->chain_node);
|
2021-03-24 05:50:08 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_OF
|
|
|
|
DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
|
|
|
|
bridge->of_node, encoder->name, ret);
|
|
|
|
#else
|
|
|
|
DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
|
|
|
|
encoder->name, ret);
|
|
|
|
#endif
|
|
|
|
|
2020-01-28 21:55:03 +08:00
|
|
|
return ret;
|
2015-01-21 00:38:44 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_bridge_attach);
|
|
|
|
|
2016-08-25 17:04:32 +08:00
|
|
|
void drm_bridge_detach(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (WARN_ON(!bridge))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (WARN_ON(!bridge->dev))
|
|
|
|
return;
|
|
|
|
|
2020-01-28 21:55:03 +08:00
|
|
|
if (bridge->funcs->atomic_reset)
|
|
|
|
drm_atomic_private_obj_fini(&bridge->base);
|
|
|
|
|
2016-08-25 17:04:32 +08:00
|
|
|
if (bridge->funcs->detach)
|
|
|
|
bridge->funcs->detach(bridge);
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
list_del(&bridge->chain_node);
|
2016-08-25 17:04:32 +08:00
|
|
|
bridge->dev = NULL;
|
|
|
|
}
|
|
|
|
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
2020-02-26 19:24:26 +08:00
|
|
|
* DOC: bridge operations
|
|
|
|
*
|
|
|
|
* Bridge drivers expose operations through the &drm_bridge_funcs structure.
|
|
|
|
* The DRM internals (atomic and CRTC helpers) use the helpers defined in
|
|
|
|
* drm_bridge.c to call bridge operations. Those operations are divided in
|
2020-02-26 19:24:27 +08:00
|
|
|
* three big categories to support different parts of the bridge usage.
|
2020-02-26 19:24:26 +08:00
|
|
|
*
|
|
|
|
* - The encoder-related operations support control of the bridges in the
|
|
|
|
* chain, and are roughly counterparts to the &drm_encoder_helper_funcs
|
|
|
|
* operations. They are used by the legacy CRTC and the atomic modeset
|
|
|
|
* helpers to perform mode validation, fixup and setting, and enable and
|
|
|
|
* disable the bridge automatically.
|
|
|
|
*
|
|
|
|
* The enable and disable operations are split in
|
|
|
|
* &drm_bridge_funcs.pre_enable, &drm_bridge_funcs.enable,
|
|
|
|
* &drm_bridge_funcs.disable and &drm_bridge_funcs.post_disable to provide
|
|
|
|
* finer-grained control.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2020-02-26 19:24:26 +08:00
|
|
|
* Bridge drivers may implement the legacy version of those operations, or
|
|
|
|
* the atomic version (prefixed with atomic\_), in which case they shall also
|
|
|
|
* implement the atomic state bookkeeping operations
|
|
|
|
* (&drm_bridge_funcs.atomic_duplicate_state,
|
|
|
|
* &drm_bridge_funcs.atomic_destroy_state and &drm_bridge_funcs.reset).
|
|
|
|
* Mixing atomic and non-atomic versions of the operations is not supported.
|
2015-05-21 13:33:17 +08:00
|
|
|
*
|
2020-02-26 19:24:26 +08:00
|
|
|
* - The bus format negotiation operations
|
|
|
|
* &drm_bridge_funcs.atomic_get_output_bus_fmts and
|
|
|
|
* &drm_bridge_funcs.atomic_get_input_bus_fmts allow bridge drivers to
|
|
|
|
* negotiate the formats transmitted between bridges in the chain when
|
|
|
|
* multiple formats are supported. Negotiation for formats is performed
|
|
|
|
* transparently for display drivers by the atomic modeset helpers. Only
|
|
|
|
* atomic versions of those operations exist, bridge drivers that need to
|
|
|
|
* implement them shall thus also implement the atomic version of the
|
|
|
|
* encoder-related operations. This feature is not supported by the legacy
|
|
|
|
* CRTC helpers.
|
2020-02-26 19:24:27 +08:00
|
|
|
*
|
|
|
|
* - The connector-related operations support implementing a &drm_connector
|
|
|
|
* based on a chain of bridges. DRM bridges traditionally create a
|
|
|
|
* &drm_connector for bridges meant to be used at the end of the chain. This
|
|
|
|
* puts additional burden on bridge drivers, especially for bridges that may
|
|
|
|
* be used in the middle of a chain or at the end of it. Furthermore, it
|
|
|
|
* requires all operations of the &drm_connector to be handled by a single
|
|
|
|
* bridge, which doesn't always match the hardware architecture.
|
|
|
|
*
|
|
|
|
* To simplify bridge drivers and make the connector implementation more
|
|
|
|
* flexible, a new model allows bridges to unconditionally skip creation of
|
|
|
|
* &drm_connector and instead expose &drm_bridge_funcs operations to support
|
|
|
|
* an externally-implemented &drm_connector. Those operations are
|
|
|
|
* &drm_bridge_funcs.detect, &drm_bridge_funcs.get_modes,
|
|
|
|
* &drm_bridge_funcs.get_edid, &drm_bridge_funcs.hpd_notify,
|
|
|
|
* &drm_bridge_funcs.hpd_enable and &drm_bridge_funcs.hpd_disable. When
|
|
|
|
* implemented, display drivers shall create a &drm_connector instance for
|
|
|
|
* each chain of bridges, and implement those connector instances based on
|
|
|
|
* the bridge connector operations.
|
|
|
|
*
|
|
|
|
* Bridge drivers shall implement the connector-related operations for all
|
|
|
|
* the features that the bridge hardware support. For instance, if a bridge
|
|
|
|
* supports reading EDID, the &drm_bridge_funcs.get_edid shall be
|
|
|
|
* implemented. This however doesn't mean that the DDC lines are wired to the
|
|
|
|
* bridge on a particular platform, as they could also be connected to an I2C
|
|
|
|
* controller of the SoC. Support for the connector-related operations on the
|
|
|
|
* running platform is reported through the &drm_bridge.ops flags. Bridge
|
|
|
|
* drivers shall detect which operations they can support on the platform
|
|
|
|
* (usually this information is provided by ACPI or DT), and set the
|
|
|
|
* &drm_bridge.ops flags for all supported operations. A flag shall only be
|
|
|
|
* set if the corresponding &drm_bridge_funcs operation is implemented, but
|
|
|
|
* an implemented operation doesn't necessarily imply that the corresponding
|
|
|
|
* flag will be set. Display drivers shall use the &drm_bridge.ops flags to
|
|
|
|
* decide which bridge to delegate a connector operation to. This mechanism
|
|
|
|
* allows providing a single static const &drm_bridge_funcs instance in
|
|
|
|
* bridge drivers, improving security by storing function pointers in
|
|
|
|
* read-only memory.
|
drm/bridge: Extend bridge API to disable connector creation
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 <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
2020-02-26 19:24:29 +08:00
|
|
|
*
|
|
|
|
* In order to ease transition, bridge drivers may support both the old and
|
|
|
|
* new models by making connector creation optional and implementing the
|
|
|
|
* connected-related bridge operations. Connector creation is then controlled
|
|
|
|
* by the flags argument to the drm_bridge_attach() function. Display drivers
|
|
|
|
* that support the new model and create connectors themselves shall set the
|
|
|
|
* %DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, and bridge drivers shall then skip
|
|
|
|
* connector creation. For intermediate bridges in the chain, the flag shall
|
|
|
|
* be passed to the drm_bridge_attach() call for the downstream bridge.
|
|
|
|
* Bridge drivers that implement the new model only shall return an error
|
|
|
|
* from their &drm_bridge_funcs.attach handler when the
|
|
|
|
* %DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not set. New display drivers
|
|
|
|
* should use the new model, and convert the bridge drivers they use if
|
|
|
|
* needed, in order to gradually transition to the new model.
|
2015-05-21 13:33:17 +08:00
|
|
|
*/
|
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_bridge_chain_mode_fixup - fixup proposed mode for all bridges in the
|
|
|
|
* encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @mode: desired mode to be set for the bridge
|
|
|
|
* @adjusted_mode: updated mode that works for this bridge
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.mode_fixup for all the bridges in the
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* encoder chain, starting from the first bridge to the last.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* true on success, false on failure
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
bool drm_bridge_chain_mode_fixup(struct drm_bridge *bridge,
|
|
|
|
const struct drm_display_mode *mode,
|
|
|
|
struct drm_display_mode *adjusted_mode)
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
|
|
|
if (!bridge)
|
|
|
|
return true;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_from(bridge, &encoder->bridge_chain, chain_node) {
|
|
|
|
if (!bridge->funcs->mode_fixup)
|
|
|
|
continue;
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
if (!bridge->funcs->mode_fixup(bridge, mode, adjusted_mode))
|
|
|
|
return false;
|
|
|
|
}
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
return true;
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_bridge_chain_mode_fixup);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
2017-05-25 22:19:14 +08:00
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_bridge_chain_mode_valid - validate the mode against all bridges in the
|
|
|
|
* encoder chain.
|
2017-05-25 22:19:14 +08:00
|
|
|
* @bridge: bridge control structure
|
2020-05-26 09:14:48 +08:00
|
|
|
* @info: display info against which the mode shall be validated
|
2017-05-25 22:19:14 +08:00
|
|
|
* @mode: desired mode to be validated
|
|
|
|
*
|
|
|
|
* Calls &drm_bridge_funcs.mode_valid for all the bridges in the encoder
|
|
|
|
* chain, starting from the first bridge to the last. If at least one bridge
|
|
|
|
* does not accept the mode the function returns the error code.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* MODE_OK on success, drm_mode_status Enum error code on failure
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
enum drm_mode_status
|
|
|
|
drm_bridge_chain_mode_valid(struct drm_bridge *bridge,
|
2020-05-26 09:14:48 +08:00
|
|
|
const struct drm_display_info *info,
|
2019-12-03 22:15:05 +08:00
|
|
|
const struct drm_display_mode *mode)
|
2017-05-25 22:19:14 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
2017-05-25 22:19:14 +08:00
|
|
|
|
|
|
|
if (!bridge)
|
2019-12-03 22:15:08 +08:00
|
|
|
return MODE_OK;
|
2017-05-25 22:19:14 +08:00
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_from(bridge, &encoder->bridge_chain, chain_node) {
|
|
|
|
enum drm_mode_status ret;
|
|
|
|
|
|
|
|
if (!bridge->funcs->mode_valid)
|
|
|
|
continue;
|
2017-05-25 22:19:14 +08:00
|
|
|
|
2020-05-26 09:14:48 +08:00
|
|
|
ret = bridge->funcs->mode_valid(bridge, info, mode);
|
2019-12-03 22:15:08 +08:00
|
|
|
if (ret != MODE_OK)
|
|
|
|
return ret;
|
|
|
|
}
|
2017-05-25 22:19:14 +08:00
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
return MODE_OK;
|
2017-05-25 22:19:14 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_bridge_chain_mode_valid);
|
2017-05-25 22:19:14 +08:00
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_bridge_chain_disable - disables all bridges in the encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.disable op for all the bridges in the encoder
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* chain, starting from the last bridge to the first. These are called before
|
|
|
|
* calling the encoder's prepare op.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_bridge_chain_disable(struct drm_bridge *bridge)
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
struct drm_bridge *iter;
|
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_reverse(iter, &encoder->bridge_chain, chain_node) {
|
|
|
|
if (iter->funcs->disable)
|
|
|
|
iter->funcs->disable(iter);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
if (iter == bridge)
|
|
|
|
break;
|
|
|
|
}
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_bridge_chain_disable);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_bridge_chain_post_disable - cleans up after disabling all bridges in the
|
|
|
|
* encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.post_disable op for all the bridges in the
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* encoder chain, starting from the first bridge to the last. These are called
|
|
|
|
* after completing the encoder's prepare op.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_bridge_chain_post_disable(struct drm_bridge *bridge)
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_from(bridge, &encoder->bridge_chain, chain_node) {
|
|
|
|
if (bridge->funcs->post_disable)
|
|
|
|
bridge->funcs->post_disable(bridge);
|
|
|
|
}
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_bridge_chain_post_disable);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_bridge_chain_mode_set - set proposed mode for all bridges in the
|
|
|
|
* encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
2019-12-03 22:15:05 +08:00
|
|
|
* @mode: desired mode to be set for the encoder chain
|
|
|
|
* @adjusted_mode: updated mode that works for this encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.mode_set op for all the bridges in the
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* encoder chain, starting from the first bridge to the last.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_bridge_chain_mode_set(struct drm_bridge *bridge,
|
|
|
|
const struct drm_display_mode *mode,
|
|
|
|
const struct drm_display_mode *adjusted_mode)
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_from(bridge, &encoder->bridge_chain, chain_node) {
|
|
|
|
if (bridge->funcs->mode_set)
|
|
|
|
bridge->funcs->mode_set(bridge, mode, adjusted_mode);
|
|
|
|
}
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_bridge_chain_mode_set);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_bridge_chain_pre_enable - prepares for enabling all bridges in the
|
|
|
|
* encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.pre_enable op for all the bridges in the encoder
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* chain, starting from the last bridge to the first. These are called
|
|
|
|
* before calling the encoder's commit op.
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_bridge_chain_pre_enable(struct drm_bridge *bridge)
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
struct drm_bridge *iter;
|
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_reverse(iter, &encoder->bridge_chain, chain_node) {
|
|
|
|
if (iter->funcs->pre_enable)
|
|
|
|
iter->funcs->pre_enable(iter);
|
2021-04-17 06:39:24 +08:00
|
|
|
|
|
|
|
if (iter == bridge)
|
|
|
|
break;
|
2019-12-03 22:15:08 +08:00
|
|
|
}
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_bridge_chain_pre_enable);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_bridge_chain_enable - enables all bridges in the encoder chain
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* Calls &drm_bridge_funcs.enable op for all the bridges in the encoder
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
* chain, starting from the first bridge to the last. These are called
|
|
|
|
* after completing the encoder's commit op.
|
|
|
|
*
|
|
|
|
* Note that the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_bridge_chain_enable(struct drm_bridge *bridge)
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_from(bridge, &encoder->bridge_chain, chain_node) {
|
|
|
|
if (bridge->funcs->enable)
|
|
|
|
bridge->funcs->enable(bridge);
|
|
|
|
}
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_bridge_chain_enable);
|
drm: bridge: Allow daisy chaining of bridges
Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have multiple devices between the encoder and the
connector/panel that require some sort of configuration.
We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding
'drm_bridge_funcs' op for the entire chain of bridges. These helpers are
used internally by drm_atomic_helper.c and drm_crtc_helper.c.
The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of
the bridge closet to the encoder, and proceed until the last bridge in the
chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup
helpers. The drm_bridge_disable/post_disable helpers disable the last
bridge in the chain first, and proceed until the first bridge in the chain
is disabled.
drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in
which the bridges are connected to each other determines the order in which
the calls are made. One requirement is that every bridge in the chain
should point the parent encoder object. This is required since bridge
drivers expect a valid encoder pointer in drm_bridge. For example, consider
a chain where an encoder's output is connected to bridge1, and bridge1's
output is connected to bridge2:
/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..
/*
* set the first bridge's 'next' bridge to bridge2, set its encoder
* as bridge1's encoder
*/
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);
...
...
This method of bridge chaining isn't intrusive and existing drivers that
use drm_bridge will behave the same way as before. The bridge helpers also
cleans up the atomic and crtc helper files a bit.
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-21 13:33:16 +08:00
|
|
|
|
2019-06-12 00:08:17 +08:00
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_atomic_bridge_chain_disable - disables all bridges in the encoder chain
|
2019-06-12 00:08:17 +08:00
|
|
|
* @bridge: bridge control structure
|
2019-12-03 22:15:11 +08:00
|
|
|
* @old_state: old atomic state
|
2019-06-12 00:08:17 +08:00
|
|
|
*
|
|
|
|
* Calls &drm_bridge_funcs.atomic_disable (falls back on
|
|
|
|
* &drm_bridge_funcs.disable) op for all the bridges in the encoder chain,
|
|
|
|
* starting from the last bridge to the first. These are called before calling
|
|
|
|
* &drm_encoder_helper_funcs.atomic_disable
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_atomic_bridge_chain_disable(struct drm_bridge *bridge,
|
2019-12-03 22:15:11 +08:00
|
|
|
struct drm_atomic_state *old_state)
|
2019-06-12 00:08:17 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
struct drm_bridge *iter;
|
|
|
|
|
2019-06-12 00:08:17 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_reverse(iter, &encoder->bridge_chain, chain_node) {
|
2020-01-28 21:55:06 +08:00
|
|
|
if (iter->funcs->atomic_disable) {
|
|
|
|
struct drm_bridge_state *old_bridge_state;
|
|
|
|
|
|
|
|
old_bridge_state =
|
|
|
|
drm_atomic_get_old_bridge_state(old_state,
|
|
|
|
iter);
|
|
|
|
if (WARN_ON(!old_bridge_state))
|
|
|
|
return;
|
|
|
|
|
|
|
|
iter->funcs->atomic_disable(iter, old_bridge_state);
|
|
|
|
} else if (iter->funcs->disable) {
|
2019-12-03 22:15:08 +08:00
|
|
|
iter->funcs->disable(iter);
|
2020-01-28 21:55:06 +08:00
|
|
|
}
|
2019-06-12 00:08:17 +08:00
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
if (iter == bridge)
|
|
|
|
break;
|
|
|
|
}
|
2019-06-12 00:08:17 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_atomic_bridge_chain_disable);
|
2019-06-12 00:08:17 +08:00
|
|
|
|
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_atomic_bridge_chain_post_disable - cleans up after disabling all bridges
|
|
|
|
* in the encoder chain
|
2019-06-12 00:08:17 +08:00
|
|
|
* @bridge: bridge control structure
|
2019-12-03 22:15:11 +08:00
|
|
|
* @old_state: old atomic state
|
2019-06-12 00:08:17 +08:00
|
|
|
*
|
|
|
|
* Calls &drm_bridge_funcs.atomic_post_disable (falls back on
|
|
|
|
* &drm_bridge_funcs.post_disable) op for all the bridges in the encoder chain,
|
|
|
|
* starting from the first bridge to the last. These are called after completing
|
|
|
|
* &drm_encoder_helper_funcs.atomic_disable
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
|
2019-12-03 22:15:11 +08:00
|
|
|
struct drm_atomic_state *old_state)
|
2019-06-12 00:08:17 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
|
2019-06-12 00:08:17 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_from(bridge, &encoder->bridge_chain, chain_node) {
|
2020-01-28 21:55:06 +08:00
|
|
|
if (bridge->funcs->atomic_post_disable) {
|
|
|
|
struct drm_bridge_state *old_bridge_state;
|
|
|
|
|
|
|
|
old_bridge_state =
|
|
|
|
drm_atomic_get_old_bridge_state(old_state,
|
|
|
|
bridge);
|
|
|
|
if (WARN_ON(!old_bridge_state))
|
|
|
|
return;
|
|
|
|
|
|
|
|
bridge->funcs->atomic_post_disable(bridge,
|
|
|
|
old_bridge_state);
|
|
|
|
} else if (bridge->funcs->post_disable) {
|
2019-12-03 22:15:08 +08:00
|
|
|
bridge->funcs->post_disable(bridge);
|
2020-01-28 21:55:06 +08:00
|
|
|
}
|
2019-12-03 22:15:08 +08:00
|
|
|
}
|
2019-06-12 00:08:17 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_atomic_bridge_chain_post_disable);
|
2019-06-12 00:08:17 +08:00
|
|
|
|
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_atomic_bridge_chain_pre_enable - prepares for enabling all bridges in
|
|
|
|
* the encoder chain
|
2019-06-12 00:08:17 +08:00
|
|
|
* @bridge: bridge control structure
|
2019-12-03 22:15:11 +08:00
|
|
|
* @old_state: old atomic state
|
2019-06-12 00:08:17 +08:00
|
|
|
*
|
|
|
|
* Calls &drm_bridge_funcs.atomic_pre_enable (falls back on
|
|
|
|
* &drm_bridge_funcs.pre_enable) op for all the bridges in the encoder chain,
|
|
|
|
* starting from the last bridge to the first. These are called before calling
|
|
|
|
* &drm_encoder_helper_funcs.atomic_enable
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_atomic_bridge_chain_pre_enable(struct drm_bridge *bridge,
|
2019-12-03 22:15:11 +08:00
|
|
|
struct drm_atomic_state *old_state)
|
2019-06-12 00:08:17 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
struct drm_bridge *iter;
|
|
|
|
|
2019-06-12 00:08:17 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_reverse(iter, &encoder->bridge_chain, chain_node) {
|
2020-01-28 21:55:06 +08:00
|
|
|
if (iter->funcs->atomic_pre_enable) {
|
|
|
|
struct drm_bridge_state *old_bridge_state;
|
|
|
|
|
|
|
|
old_bridge_state =
|
|
|
|
drm_atomic_get_old_bridge_state(old_state,
|
|
|
|
iter);
|
|
|
|
if (WARN_ON(!old_bridge_state))
|
|
|
|
return;
|
|
|
|
|
|
|
|
iter->funcs->atomic_pre_enable(iter, old_bridge_state);
|
|
|
|
} else if (iter->funcs->pre_enable) {
|
2019-12-03 22:15:08 +08:00
|
|
|
iter->funcs->pre_enable(iter);
|
2020-01-28 21:55:06 +08:00
|
|
|
}
|
2019-06-12 00:08:17 +08:00
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
if (iter == bridge)
|
|
|
|
break;
|
|
|
|
}
|
2019-06-12 00:08:17 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_atomic_bridge_chain_pre_enable);
|
2019-06-12 00:08:17 +08:00
|
|
|
|
|
|
|
/**
|
2019-12-03 22:15:05 +08:00
|
|
|
* drm_atomic_bridge_chain_enable - enables all bridges in the encoder chain
|
2019-06-12 00:08:17 +08:00
|
|
|
* @bridge: bridge control structure
|
2019-12-03 22:15:11 +08:00
|
|
|
* @old_state: old atomic state
|
2019-06-12 00:08:17 +08:00
|
|
|
*
|
|
|
|
* Calls &drm_bridge_funcs.atomic_enable (falls back on
|
|
|
|
* &drm_bridge_funcs.enable) op for all the bridges in the encoder chain,
|
|
|
|
* starting from the first bridge to the last. These are called after completing
|
|
|
|
* &drm_encoder_helper_funcs.atomic_enable
|
|
|
|
*
|
|
|
|
* Note: the bridge passed should be the one closest to the encoder
|
|
|
|
*/
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_atomic_bridge_chain_enable(struct drm_bridge *bridge,
|
2019-12-03 22:15:11 +08:00
|
|
|
struct drm_atomic_state *old_state)
|
2019-06-12 00:08:17 +08:00
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
|
2019-06-12 00:08:17 +08:00
|
|
|
if (!bridge)
|
|
|
|
return;
|
|
|
|
|
2019-12-03 22:15:08 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_from(bridge, &encoder->bridge_chain, chain_node) {
|
2020-01-28 21:55:06 +08:00
|
|
|
if (bridge->funcs->atomic_enable) {
|
|
|
|
struct drm_bridge_state *old_bridge_state;
|
|
|
|
|
|
|
|
old_bridge_state =
|
|
|
|
drm_atomic_get_old_bridge_state(old_state,
|
|
|
|
bridge);
|
|
|
|
if (WARN_ON(!old_bridge_state))
|
|
|
|
return;
|
|
|
|
|
|
|
|
bridge->funcs->atomic_enable(bridge, old_bridge_state);
|
|
|
|
} else if (bridge->funcs->enable) {
|
2019-12-03 22:15:08 +08:00
|
|
|
bridge->funcs->enable(bridge);
|
2020-01-28 21:55:06 +08:00
|
|
|
}
|
2019-12-03 22:15:08 +08:00
|
|
|
}
|
2019-06-12 00:08:17 +08:00
|
|
|
}
|
2019-12-03 22:15:05 +08:00
|
|
|
EXPORT_SYMBOL(drm_atomic_bridge_chain_enable);
|
2019-06-12 00:08:17 +08:00
|
|
|
|
2020-01-28 21:55:07 +08:00
|
|
|
static int drm_atomic_bridge_check(struct drm_bridge *bridge,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state)
|
|
|
|
{
|
|
|
|
if (bridge->funcs->atomic_check) {
|
|
|
|
struct drm_bridge_state *bridge_state;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
bridge_state = drm_atomic_get_new_bridge_state(crtc_state->state,
|
|
|
|
bridge);
|
|
|
|
if (WARN_ON(!bridge_state))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ret = bridge->funcs->atomic_check(bridge, bridge_state,
|
|
|
|
crtc_state, conn_state);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
} else if (bridge->funcs->mode_fixup) {
|
|
|
|
if (!bridge->funcs->mode_fixup(bridge, &crtc_state->mode,
|
|
|
|
&crtc_state->adjusted_mode))
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 21:55:08 +08:00
|
|
|
static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
|
|
|
|
struct drm_bridge *cur_bridge,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state,
|
|
|
|
u32 out_bus_fmt)
|
|
|
|
{
|
|
|
|
struct drm_bridge_state *cur_state;
|
|
|
|
unsigned int num_in_bus_fmts, i;
|
|
|
|
struct drm_bridge *prev_bridge;
|
|
|
|
u32 *in_bus_fmts;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
prev_bridge = drm_bridge_get_prev_bridge(cur_bridge);
|
|
|
|
cur_state = drm_atomic_get_new_bridge_state(crtc_state->state,
|
|
|
|
cur_bridge);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If bus format negotiation is not supported by this bridge, let's
|
|
|
|
* pass MEDIA_BUS_FMT_FIXED to the previous bridge in the chain and
|
|
|
|
* hope that it can handle this situation gracefully (by providing
|
|
|
|
* appropriate default values).
|
|
|
|
*/
|
|
|
|
if (!cur_bridge->funcs->atomic_get_input_bus_fmts) {
|
|
|
|
if (cur_bridge != first_bridge) {
|
|
|
|
ret = select_bus_fmt_recursive(first_bridge,
|
|
|
|
prev_bridge, crtc_state,
|
|
|
|
conn_state,
|
|
|
|
MEDIA_BUS_FMT_FIXED);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Driver does not implement the atomic state hooks, but that's
|
|
|
|
* fine, as long as it does not access the bridge state.
|
|
|
|
*/
|
|
|
|
if (cur_state) {
|
|
|
|
cur_state->input_bus_cfg.format = MEDIA_BUS_FMT_FIXED;
|
|
|
|
cur_state->output_bus_cfg.format = out_bus_fmt;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the driver implements ->atomic_get_input_bus_fmts() it
|
|
|
|
* should also implement the atomic state hooks.
|
|
|
|
*/
|
|
|
|
if (WARN_ON(!cur_state))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
in_bus_fmts = cur_bridge->funcs->atomic_get_input_bus_fmts(cur_bridge,
|
|
|
|
cur_state,
|
|
|
|
crtc_state,
|
|
|
|
conn_state,
|
|
|
|
out_bus_fmt,
|
|
|
|
&num_in_bus_fmts);
|
|
|
|
if (!num_in_bus_fmts)
|
|
|
|
return -ENOTSUPP;
|
|
|
|
else if (!in_bus_fmts)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (first_bridge == cur_bridge) {
|
|
|
|
cur_state->input_bus_cfg.format = in_bus_fmts[0];
|
|
|
|
cur_state->output_bus_cfg.format = out_bus_fmt;
|
|
|
|
kfree(in_bus_fmts);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < num_in_bus_fmts; i++) {
|
|
|
|
ret = select_bus_fmt_recursive(first_bridge, prev_bridge,
|
|
|
|
crtc_state, conn_state,
|
|
|
|
in_bus_fmts[i]);
|
|
|
|
if (ret != -ENOTSUPP)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ret) {
|
|
|
|
cur_state->input_bus_cfg.format = in_bus_fmts[i];
|
|
|
|
cur_state->output_bus_cfg.format = out_bus_fmt;
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(in_bus_fmts);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function is called by &drm_atomic_bridge_chain_check() just before
|
|
|
|
* calling &drm_bridge_funcs.atomic_check() on all elements of the chain.
|
|
|
|
* It performs bus format negotiation between bridge elements. The negotiation
|
|
|
|
* happens in reverse order, starting from the last element in the chain up to
|
|
|
|
* @bridge.
|
|
|
|
*
|
|
|
|
* Negotiation starts by retrieving supported output bus formats on the last
|
|
|
|
* bridge element and testing them one by one. The test is recursive, meaning
|
|
|
|
* that for each tested output format, the whole chain will be walked backward,
|
|
|
|
* and each element will have to choose an input bus format that can be
|
|
|
|
* transcoded to the requested output format. When a bridge element does not
|
|
|
|
* support transcoding into a specific output format -ENOTSUPP is returned and
|
|
|
|
* the next bridge element will have to try a different format. If none of the
|
|
|
|
* combinations worked, -ENOTSUPP is returned and the atomic modeset will fail.
|
|
|
|
*
|
|
|
|
* This implementation is relying on
|
|
|
|
* &drm_bridge_funcs.atomic_get_output_bus_fmts() and
|
|
|
|
* &drm_bridge_funcs.atomic_get_input_bus_fmts() to gather supported
|
|
|
|
* input/output formats.
|
|
|
|
*
|
|
|
|
* When &drm_bridge_funcs.atomic_get_output_bus_fmts() is not implemented by
|
|
|
|
* the last element of the chain, &drm_atomic_bridge_chain_select_bus_fmts()
|
|
|
|
* tries a single format: &drm_connector.display_info.bus_formats[0] if
|
|
|
|
* available, MEDIA_BUS_FMT_FIXED otherwise.
|
|
|
|
*
|
|
|
|
* When &drm_bridge_funcs.atomic_get_input_bus_fmts() is not implemented,
|
|
|
|
* &drm_atomic_bridge_chain_select_bus_fmts() skips the negotiation on the
|
|
|
|
* bridge element that lacks this hook and asks the previous element in the
|
|
|
|
* chain to try MEDIA_BUS_FMT_FIXED. It's up to bridge drivers to decide what
|
|
|
|
* to do in that case (fail if they want to enforce bus format negotiation, or
|
|
|
|
* provide a reasonable default if they need to support pipelines where not
|
|
|
|
* all elements support bus format negotiation).
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state)
|
|
|
|
{
|
|
|
|
struct drm_connector *conn = conn_state->connector;
|
|
|
|
struct drm_encoder *encoder = bridge->encoder;
|
|
|
|
struct drm_bridge_state *last_bridge_state;
|
|
|
|
unsigned int i, num_out_bus_fmts;
|
|
|
|
struct drm_bridge *last_bridge;
|
|
|
|
u32 *out_bus_fmts;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
last_bridge = list_last_entry(&encoder->bridge_chain,
|
|
|
|
struct drm_bridge, chain_node);
|
|
|
|
last_bridge_state = drm_atomic_get_new_bridge_state(crtc_state->state,
|
|
|
|
last_bridge);
|
|
|
|
|
|
|
|
if (last_bridge->funcs->atomic_get_output_bus_fmts) {
|
|
|
|
const struct drm_bridge_funcs *funcs = last_bridge->funcs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the driver implements ->atomic_get_output_bus_fmts() it
|
|
|
|
* should also implement the atomic state hooks.
|
|
|
|
*/
|
|
|
|
if (WARN_ON(!last_bridge_state))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
out_bus_fmts = funcs->atomic_get_output_bus_fmts(last_bridge,
|
|
|
|
last_bridge_state,
|
|
|
|
crtc_state,
|
|
|
|
conn_state,
|
|
|
|
&num_out_bus_fmts);
|
|
|
|
if (!num_out_bus_fmts)
|
|
|
|
return -ENOTSUPP;
|
|
|
|
else if (!out_bus_fmts)
|
|
|
|
return -ENOMEM;
|
|
|
|
} else {
|
|
|
|
num_out_bus_fmts = 1;
|
|
|
|
out_bus_fmts = kmalloc(sizeof(*out_bus_fmts), GFP_KERNEL);
|
|
|
|
if (!out_bus_fmts)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (conn->display_info.num_bus_formats &&
|
|
|
|
conn->display_info.bus_formats)
|
|
|
|
out_bus_fmts[0] = conn->display_info.bus_formats[0];
|
|
|
|
else
|
|
|
|
out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < num_out_bus_fmts; i++) {
|
|
|
|
ret = select_bus_fmt_recursive(bridge, last_bridge, crtc_state,
|
|
|
|
conn_state, out_bus_fmts[i]);
|
|
|
|
if (ret != -ENOTSUPP)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(out_bus_fmts);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
drm_atomic_bridge_propagate_bus_flags(struct drm_bridge *bridge,
|
|
|
|
struct drm_connector *conn,
|
|
|
|
struct drm_atomic_state *state)
|
|
|
|
{
|
|
|
|
struct drm_bridge_state *bridge_state, *next_bridge_state;
|
|
|
|
struct drm_bridge *next_bridge;
|
|
|
|
u32 output_flags = 0;
|
|
|
|
|
|
|
|
bridge_state = drm_atomic_get_new_bridge_state(state, bridge);
|
|
|
|
|
|
|
|
/* No bridge state attached to this bridge => nothing to propagate. */
|
|
|
|
if (!bridge_state)
|
|
|
|
return;
|
|
|
|
|
|
|
|
next_bridge = drm_bridge_get_next_bridge(bridge);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Let's try to apply the most common case here, that is, propagate
|
|
|
|
* display_info flags for the last bridge, and propagate the input
|
|
|
|
* flags of the next bridge element to the output end of the current
|
|
|
|
* bridge when the bridge is not the last one.
|
|
|
|
* There are exceptions to this rule, like when signal inversion is
|
|
|
|
* happening at the board level, but that's something drivers can deal
|
|
|
|
* with from their &drm_bridge_funcs.atomic_check() implementation by
|
|
|
|
* simply overriding the flags value we've set here.
|
|
|
|
*/
|
|
|
|
if (!next_bridge) {
|
|
|
|
output_flags = conn->display_info.bus_flags;
|
|
|
|
} else {
|
|
|
|
next_bridge_state = drm_atomic_get_new_bridge_state(state,
|
|
|
|
next_bridge);
|
|
|
|
/*
|
|
|
|
* No bridge state attached to the next bridge, just leave the
|
|
|
|
* flags to 0.
|
|
|
|
*/
|
|
|
|
if (next_bridge_state)
|
|
|
|
output_flags = next_bridge_state->input_bus_cfg.flags;
|
|
|
|
}
|
|
|
|
|
|
|
|
bridge_state->output_bus_cfg.flags = output_flags;
|
|
|
|
|
|
|
|
/*
|
2021-07-30 21:27:29 +08:00
|
|
|
* Propagate the output flags to the input end of the bridge. Again, it's
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 21:55:08 +08:00
|
|
|
* not necessarily what all bridges want, but that's what most of them
|
|
|
|
* do, and by doing that by default we avoid forcing drivers to
|
|
|
|
* duplicate the "dummy propagation" logic.
|
|
|
|
*/
|
|
|
|
bridge_state->input_bus_cfg.flags = output_flags;
|
|
|
|
}
|
|
|
|
|
2020-01-28 21:55:07 +08:00
|
|
|
/**
|
|
|
|
* drm_atomic_bridge_chain_check() - Do an atomic check on the bridge chain
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @crtc_state: new CRTC state
|
|
|
|
* @conn_state: new connector state
|
|
|
|
*
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 21:55:08 +08:00
|
|
|
* First trigger a bus format negotiation before calling
|
|
|
|
* &drm_bridge_funcs.atomic_check() (falls back on
|
2020-01-28 21:55:07 +08:00
|
|
|
* &drm_bridge_funcs.mode_fixup()) op for all the bridges in the encoder chain,
|
|
|
|
* starting from the last bridge to the first. These are called before calling
|
|
|
|
* &drm_encoder_helper_funcs.atomic_check()
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* 0 on success, a negative error code on failure
|
|
|
|
*/
|
|
|
|
int drm_atomic_bridge_chain_check(struct drm_bridge *bridge,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state)
|
|
|
|
{
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 21:55:08 +08:00
|
|
|
struct drm_connector *conn = conn_state->connector;
|
2020-01-28 21:55:07 +08:00
|
|
|
struct drm_encoder *encoder;
|
|
|
|
struct drm_bridge *iter;
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 21:55:08 +08:00
|
|
|
int ret;
|
2020-01-28 21:55:07 +08:00
|
|
|
|
|
|
|
if (!bridge)
|
|
|
|
return 0;
|
|
|
|
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 21:55:08 +08:00
|
|
|
ret = drm_atomic_bridge_chain_select_bus_fmts(bridge, crtc_state,
|
|
|
|
conn_state);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2020-01-28 21:55:07 +08:00
|
|
|
encoder = bridge->encoder;
|
|
|
|
list_for_each_entry_reverse(iter, &encoder->bridge_chain, chain_node) {
|
|
|
|
int ret;
|
|
|
|
|
drm/bridge: Add the necessary bits to support bus format negotiation
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
2020-01-28 21:55:08 +08:00
|
|
|
/*
|
|
|
|
* Bus flags are propagated by default. If a bridge needs to
|
|
|
|
* tweak the input bus flags for any reason, it should happen
|
|
|
|
* in its &drm_bridge_funcs.atomic_check() implementation such
|
|
|
|
* that preceding bridges in the chain can propagate the new
|
|
|
|
* bus flags.
|
|
|
|
*/
|
|
|
|
drm_atomic_bridge_propagate_bus_flags(iter, conn,
|
|
|
|
crtc_state->state);
|
|
|
|
|
2020-01-28 21:55:07 +08:00
|
|
|
ret = drm_atomic_bridge_check(iter, crtc_state, conn_state);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (iter == bridge)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_atomic_bridge_chain_check);
|
|
|
|
|
2020-02-26 19:24:27 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_detect - check if anything is attached to the bridge output
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
|
|
|
* If the bridge supports output detection, as reported by the
|
|
|
|
* DRM_BRIDGE_OP_DETECT bridge ops flag, call &drm_bridge_funcs.detect for the
|
|
|
|
* bridge and return the connection status. Otherwise return
|
|
|
|
* connector_status_unknown.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* The detection status on success, or connector_status_unknown if the bridge
|
|
|
|
* doesn't support output detection.
|
|
|
|
*/
|
|
|
|
enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
|
|
|
|
return connector_status_unknown;
|
|
|
|
|
|
|
|
return bridge->funcs->detect(bridge);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(drm_bridge_detect);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_bridge_get_modes - fill all modes currently valid for the sink into the
|
|
|
|
* @connector
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @connector: the connector to fill with modes
|
|
|
|
*
|
|
|
|
* If the bridge supports output modes retrieval, as reported by the
|
|
|
|
* DRM_BRIDGE_OP_MODES bridge ops flag, call &drm_bridge_funcs.get_modes to
|
|
|
|
* fill the connector with all valid modes and return the number of modes
|
|
|
|
* added. Otherwise return 0.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* The number of modes added to the connector.
|
|
|
|
*/
|
|
|
|
int drm_bridge_get_modes(struct drm_bridge *bridge,
|
|
|
|
struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
if (!(bridge->ops & DRM_BRIDGE_OP_MODES))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return bridge->funcs->get_modes(bridge, connector);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_bridge_get_edid - get the EDID data of the connected display
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @connector: the connector to read EDID for
|
|
|
|
*
|
|
|
|
* If the bridge supports output EDID retrieval, as reported by the
|
|
|
|
* DRM_BRIDGE_OP_EDID bridge ops flag, call &drm_bridge_funcs.get_edid to
|
2020-05-26 09:14:43 +08:00
|
|
|
* get the EDID and return it. Otherwise return NULL.
|
2020-02-26 19:24:27 +08:00
|
|
|
*
|
|
|
|
* RETURNS:
|
2020-05-26 09:14:43 +08:00
|
|
|
* The retrieved EDID on success, or NULL otherwise.
|
2020-02-26 19:24:27 +08:00
|
|
|
*/
|
|
|
|
struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
|
|
|
|
struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
|
2020-05-26 09:14:43 +08:00
|
|
|
return NULL;
|
2020-02-26 19:24:27 +08:00
|
|
|
|
|
|
|
return bridge->funcs->get_edid(bridge, connector);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(drm_bridge_get_edid);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_bridge_hpd_enable - enable hot plug detection for the bridge
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @cb: hot-plug detection callback
|
|
|
|
* @data: data to be passed to the hot-plug detection callback
|
|
|
|
*
|
|
|
|
* Call &drm_bridge_funcs.hpd_enable if implemented and register the given @cb
|
|
|
|
* and @data as hot plug notification callback. From now on the @cb will be
|
|
|
|
* called with @data when an output status change is detected by the bridge,
|
|
|
|
* until hot plug notification gets disabled with drm_bridge_hpd_disable().
|
|
|
|
*
|
|
|
|
* Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
|
|
|
|
* bridge->ops. This function shall not be called when the flag is not set.
|
|
|
|
*
|
|
|
|
* Only one hot plug detection callback can be registered at a time, it is an
|
|
|
|
* error to call this function when hot plug detection is already enabled for
|
|
|
|
* the bridge.
|
|
|
|
*/
|
|
|
|
void drm_bridge_hpd_enable(struct drm_bridge *bridge,
|
|
|
|
void (*cb)(void *data,
|
|
|
|
enum drm_connector_status status),
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
if (!(bridge->ops & DRM_BRIDGE_OP_HPD))
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&bridge->hpd_mutex);
|
|
|
|
|
|
|
|
if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
bridge->hpd_cb = cb;
|
|
|
|
bridge->hpd_data = data;
|
|
|
|
|
|
|
|
if (bridge->funcs->hpd_enable)
|
|
|
|
bridge->funcs->hpd_enable(bridge);
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&bridge->hpd_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_bridge_hpd_disable - disable hot plug detection for the bridge
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
*
|
|
|
|
* Call &drm_bridge_funcs.hpd_disable if implemented and unregister the hot
|
|
|
|
* plug detection callback previously registered with drm_bridge_hpd_enable().
|
|
|
|
* Once this function returns the callback will not be called by the bridge
|
|
|
|
* when an output status change occurs.
|
|
|
|
*
|
|
|
|
* Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
|
|
|
|
* bridge->ops. This function shall not be called when the flag is not set.
|
|
|
|
*/
|
|
|
|
void drm_bridge_hpd_disable(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (!(bridge->ops & DRM_BRIDGE_OP_HPD))
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&bridge->hpd_mutex);
|
|
|
|
if (bridge->funcs->hpd_disable)
|
|
|
|
bridge->funcs->hpd_disable(bridge);
|
|
|
|
|
|
|
|
bridge->hpd_cb = NULL;
|
|
|
|
bridge->hpd_data = NULL;
|
|
|
|
mutex_unlock(&bridge->hpd_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_bridge_hpd_notify - notify hot plug detection events
|
|
|
|
* @bridge: bridge control structure
|
|
|
|
* @status: output connection status
|
|
|
|
*
|
|
|
|
* Bridge drivers shall call this function to report hot plug events when they
|
|
|
|
* detect a change in the output status, when hot plug detection has been
|
|
|
|
* enabled by drm_bridge_hpd_enable().
|
|
|
|
*
|
|
|
|
* This function shall be called in a context that can sleep.
|
|
|
|
*/
|
|
|
|
void drm_bridge_hpd_notify(struct drm_bridge *bridge,
|
|
|
|
enum drm_connector_status status)
|
|
|
|
{
|
|
|
|
mutex_lock(&bridge->hpd_mutex);
|
|
|
|
if (bridge->hpd_cb)
|
|
|
|
bridge->hpd_cb(bridge->hpd_data, status);
|
|
|
|
mutex_unlock(&bridge->hpd_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
|
|
|
|
|
2015-01-21 00:38:44 +08:00
|
|
|
#ifdef CONFIG_OF
|
2015-05-21 13:33:17 +08:00
|
|
|
/**
|
|
|
|
* of_drm_find_bridge - find the bridge corresponding to the device node in
|
|
|
|
* the global bridge list
|
|
|
|
*
|
|
|
|
* @np: device node
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* drm_bridge control struct on success, NULL on failure
|
|
|
|
*/
|
2015-01-21 00:38:44 +08:00
|
|
|
struct drm_bridge *of_drm_find_bridge(struct device_node *np)
|
|
|
|
{
|
|
|
|
struct drm_bridge *bridge;
|
|
|
|
|
|
|
|
mutex_lock(&bridge_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(bridge, &bridge_list, list) {
|
|
|
|
if (bridge->of_node == np) {
|
|
|
|
mutex_unlock(&bridge_lock);
|
|
|
|
return bridge;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&bridge_lock);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(of_drm_find_bridge);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Ajay Kumar <ajaykumar.rs@samsung.com>");
|
|
|
|
MODULE_DESCRIPTION("DRM bridge infrastructure");
|
|
|
|
MODULE_LICENSE("GPL and additional rights");
|