2016-09-01 00:09:05 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2016 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, distribute, and sell this software and its
|
|
|
|
* documentation for any purpose is hereby granted without fee, provided that
|
|
|
|
* the above copyright notice appear in all copies and that both that copyright
|
|
|
|
* notice and this permission notice appear in supporting documentation, and
|
|
|
|
* that the name of the copyright holders not be used in advertising or
|
|
|
|
* publicity pertaining to distribution of the software without specific,
|
|
|
|
* written prior permission. The copyright holders make no representations
|
|
|
|
* about the suitability of this software for any purpose. It is provided "as
|
|
|
|
* is" without express or implied warranty.
|
|
|
|
*
|
|
|
|
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
|
|
|
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
|
|
|
|
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
|
|
|
|
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
|
|
|
|
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
|
|
|
|
* OF THIS SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __DRM_BRIDGE_H__
|
|
|
|
#define __DRM_BRIDGE_H__
|
|
|
|
|
|
|
|
#include <linux/ctype.h>
|
2020-02-26 19:24:27 +08:00
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/mutex.h>
|
2020-01-28 21:55:03 +08:00
|
|
|
|
|
|
|
#include <drm/drm_atomic.h>
|
2019-12-03 22:15:07 +08:00
|
|
|
#include <drm/drm_encoder.h>
|
2016-09-01 00:09:05 +08:00
|
|
|
#include <drm/drm_mode_object.h>
|
|
|
|
#include <drm/drm_modes.h>
|
|
|
|
|
|
|
|
struct drm_bridge;
|
2018-01-12 15:48:52 +08:00
|
|
|
struct drm_bridge_timings;
|
2020-02-26 19:24:27 +08:00
|
|
|
struct drm_connector;
|
2020-05-26 09:14:48 +08:00
|
|
|
struct drm_display_info;
|
2017-06-03 04:25:14 +08:00
|
|
|
struct drm_panel;
|
2020-02-26 19:24:27 +08:00
|
|
|
struct edid;
|
|
|
|
struct i2c_adapter;
|
2016-09-01 00:09:05 +08:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
* enum drm_bridge_attach_flags - Flags for &drm_bridge_funcs.attach
|
|
|
|
*/
|
|
|
|
enum drm_bridge_attach_flags {
|
|
|
|
/**
|
|
|
|
* @DRM_BRIDGE_ATTACH_NO_CONNECTOR: When this flag is set the bridge
|
|
|
|
* shall not create a drm_connector.
|
|
|
|
*/
|
|
|
|
DRM_BRIDGE_ATTACH_NO_CONNECTOR = BIT(0),
|
|
|
|
};
|
|
|
|
|
2016-09-01 00:09:05 +08:00
|
|
|
/**
|
|
|
|
* struct drm_bridge_funcs - drm_bridge control functions
|
|
|
|
*/
|
|
|
|
struct drm_bridge_funcs {
|
|
|
|
/**
|
|
|
|
* @attach:
|
|
|
|
*
|
|
|
|
* This callback is invoked whenever our bridge is being attached to a
|
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
|
|
|
* &drm_encoder. The flags argument tunes the behaviour of the attach
|
|
|
|
* operation (see DRM_BRIDGE_ATTACH_*).
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @attach callback is optional.
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* Zero on success, error code on failure.
|
|
|
|
*/
|
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
|
|
|
int (*attach)(struct drm_bridge *bridge,
|
|
|
|
enum drm_bridge_attach_flags flags);
|
2016-09-01 00:09:05 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @detach:
|
|
|
|
*
|
|
|
|
* This callback is invoked whenever our bridge is being detached from a
|
|
|
|
* &drm_encoder.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @detach callback is optional.
|
2016-09-01 00:09:05 +08:00
|
|
|
*/
|
|
|
|
void (*detach)(struct drm_bridge *bridge);
|
|
|
|
|
2017-05-15 17:33:47 +08:00
|
|
|
/**
|
|
|
|
* @mode_valid:
|
|
|
|
*
|
|
|
|
* This callback is used to check if a specific mode is valid in this
|
|
|
|
* bridge. This should be implemented if the bridge has some sort of
|
|
|
|
* restriction in the modes it can display. For example, a given bridge
|
|
|
|
* may be responsible to set a clock value. If the clock can not
|
|
|
|
* produce all the values for the available modes then this callback
|
|
|
|
* can be used to restrict the number of modes to only the ones that
|
|
|
|
* can be displayed.
|
|
|
|
*
|
|
|
|
* This hook is used by the probe helpers to filter the mode list in
|
|
|
|
* drm_helper_probe_single_connector_modes(), and it is used by the
|
|
|
|
* atomic helpers to validate modes supplied by userspace in
|
|
|
|
* drm_atomic_helper_check_modeset().
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @mode_valid callback is optional.
|
2017-05-15 17:33:47 +08:00
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* Since this function is both called from the check phase of an atomic
|
|
|
|
* commit, and the mode validation in the probe paths it is not allowed
|
|
|
|
* to look at anything else but the passed-in mode, and validate it
|
|
|
|
* against configuration-invariant hardward constraints. Any further
|
|
|
|
* limits which depend upon the configuration can only be checked in
|
|
|
|
* @mode_fixup.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* drm_mode_status Enum
|
|
|
|
*/
|
2018-01-29 17:55:31 +08:00
|
|
|
enum drm_mode_status (*mode_valid)(struct drm_bridge *bridge,
|
2020-05-26 09:14:48 +08:00
|
|
|
const struct drm_display_info *info,
|
2017-05-15 17:33:47 +08:00
|
|
|
const struct drm_display_mode *mode);
|
|
|
|
|
2016-09-01 00:09:05 +08:00
|
|
|
/**
|
|
|
|
* @mode_fixup:
|
|
|
|
*
|
2018-05-16 04:37:36 +08:00
|
|
|
* This callback is used to validate and adjust a mode. The parameter
|
2016-09-01 00:09:05 +08:00
|
|
|
* mode is the display mode that should be fed to the next element in
|
|
|
|
* the display chain, either the final &drm_connector or the next
|
|
|
|
* &drm_bridge. The parameter adjusted_mode is the input mode the bridge
|
|
|
|
* requires. It can be modified by this callback and does not need to
|
2017-05-15 17:11:35 +08:00
|
|
|
* match mode. See also &drm_crtc_state.adjusted_mode for more details.
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
|
|
|
* This is the only hook that allows a bridge to reject a modeset. If
|
|
|
|
* this function passes all other callbacks must succeed for this
|
|
|
|
* configuration.
|
|
|
|
*
|
2020-01-28 21:55:07 +08:00
|
|
|
* The mode_fixup callback is optional. &drm_bridge_funcs.mode_fixup()
|
|
|
|
* is not called when &drm_bridge_funcs.atomic_check() is implemented,
|
|
|
|
* so only one of them should be provided.
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* This function is called in the check phase of atomic modesets, which
|
|
|
|
* can be aborted for any reason (including on userspace's request to
|
|
|
|
* just check whether a configuration would be possible). Drivers MUST
|
|
|
|
* NOT touch any persistent state (hardware or software) or data
|
|
|
|
* structures except the passed in @state parameter.
|
|
|
|
*
|
2017-05-15 17:33:47 +08:00
|
|
|
* Also beware that userspace can request its own custom modes, neither
|
|
|
|
* core nor helpers filter modes to the list of probe modes reported by
|
|
|
|
* the GETCONNECTOR IOCTL and stored in &drm_connector.modes. To ensure
|
|
|
|
* that modes are filtered consistently put any bridge constraints and
|
|
|
|
* limits checks into @mode_valid.
|
|
|
|
*
|
2016-09-01 00:09:05 +08:00
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* True if an acceptable configuration is possible, false if the modeset
|
|
|
|
* operation should be rejected.
|
|
|
|
*/
|
|
|
|
bool (*mode_fixup)(struct drm_bridge *bridge,
|
|
|
|
const struct drm_display_mode *mode,
|
|
|
|
struct drm_display_mode *adjusted_mode);
|
|
|
|
/**
|
|
|
|
* @disable:
|
|
|
|
*
|
|
|
|
* This callback should disable the bridge. It is called right before
|
|
|
|
* the preceding element in the display pipe is disabled. If the
|
|
|
|
* preceding element is a bridge this means it's called before that
|
2017-01-02 16:17:26 +08:00
|
|
|
* bridge's @disable vfunc. If the preceding element is a &drm_encoder
|
|
|
|
* it's called right before the &drm_encoder_helper_funcs.disable,
|
|
|
|
* &drm_encoder_helper_funcs.prepare or &drm_encoder_helper_funcs.dpms
|
|
|
|
* hook.
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
|
|
|
* The bridge can assume that the display pipe (i.e. clocks and timing
|
|
|
|
* signals) feeding it is still running when this callback is called.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @disable callback is optional.
|
2021-07-10 16:42:40 +08:00
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* This is deprecated, do not use!
|
|
|
|
* New drivers shall use &drm_bridge_funcs.atomic_disable.
|
2016-09-01 00:09:05 +08:00
|
|
|
*/
|
|
|
|
void (*disable)(struct drm_bridge *bridge);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @post_disable:
|
|
|
|
*
|
2017-01-02 16:17:26 +08:00
|
|
|
* This callback should disable the bridge. It is called right after the
|
|
|
|
* preceding element in the display pipe is disabled. If the preceding
|
|
|
|
* element is a bridge this means it's called after that bridge's
|
|
|
|
* @post_disable function. If the preceding element is a &drm_encoder
|
|
|
|
* it's called right after the encoder's
|
|
|
|
* &drm_encoder_helper_funcs.disable, &drm_encoder_helper_funcs.prepare
|
|
|
|
* or &drm_encoder_helper_funcs.dpms hook.
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
|
|
|
* The bridge must assume that the display pipe (i.e. clocks and timing
|
|
|
|
* singals) feeding it is no longer running when this callback is
|
|
|
|
* called.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @post_disable callback is optional.
|
2021-07-10 16:42:40 +08:00
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* This is deprecated, do not use!
|
|
|
|
* New drivers shall use &drm_bridge_funcs.atomic_post_disable.
|
2016-09-01 00:09:05 +08:00
|
|
|
*/
|
|
|
|
void (*post_disable)(struct drm_bridge *bridge);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @mode_set:
|
|
|
|
*
|
|
|
|
* This callback should set the given mode on the bridge. It is called
|
2017-01-02 16:17:26 +08:00
|
|
|
* after the @mode_set callback for the preceding element in the display
|
|
|
|
* pipeline has been called already. If the bridge is the first element
|
|
|
|
* then this would be &drm_encoder_helper_funcs.mode_set. The display
|
|
|
|
* pipe (i.e. clocks and timing signals) is off when this function is
|
|
|
|
* called.
|
2018-04-09 23:24:27 +08:00
|
|
|
*
|
|
|
|
* The adjusted_mode parameter is the mode output by the CRTC for the
|
|
|
|
* first bridge in the chain. It can be different from the mode
|
|
|
|
* parameter that contains the desired mode for the connector at the end
|
|
|
|
* of the bridges chain, for instance when the first bridge in the chain
|
|
|
|
* performs scaling. The adjusted mode is mostly useful for the first
|
|
|
|
* bridge in the chain and is likely irrelevant for the other bridges.
|
|
|
|
*
|
|
|
|
* For atomic drivers the adjusted_mode is the mode stored in
|
|
|
|
* &drm_crtc_state.adjusted_mode.
|
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
2021-07-10 16:42:40 +08:00
|
|
|
* This is deprecated, do not use!
|
|
|
|
* New drivers shall set their mode in the
|
|
|
|
* &drm_bridge_funcs.atomic_enable operation.
|
2016-09-01 00:09:05 +08:00
|
|
|
*/
|
|
|
|
void (*mode_set)(struct drm_bridge *bridge,
|
2018-04-06 22:39:01 +08:00
|
|
|
const struct drm_display_mode *mode,
|
|
|
|
const struct drm_display_mode *adjusted_mode);
|
2016-09-01 00:09:05 +08:00
|
|
|
/**
|
|
|
|
* @pre_enable:
|
|
|
|
*
|
|
|
|
* This callback should enable the bridge. It is called right before
|
|
|
|
* the preceding element in the display pipe is enabled. If the
|
|
|
|
* preceding element is a bridge this means it's called before that
|
2017-01-02 16:17:26 +08:00
|
|
|
* bridge's @pre_enable function. If the preceding element is a
|
|
|
|
* &drm_encoder it's called right before the encoder's
|
|
|
|
* &drm_encoder_helper_funcs.enable, &drm_encoder_helper_funcs.commit or
|
|
|
|
* &drm_encoder_helper_funcs.dpms hook.
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
|
|
|
* The display pipe (i.e. clocks and timing signals) feeding this bridge
|
|
|
|
* will not yet be running when this callback is called. The bridge must
|
|
|
|
* not enable the display link feeding the next bridge in the chain (if
|
|
|
|
* there is one) when this callback is called.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @pre_enable callback is optional.
|
2021-07-10 16:42:40 +08:00
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* This is deprecated, do not use!
|
|
|
|
* New drivers shall use &drm_bridge_funcs.atomic_pre_enable.
|
2016-09-01 00:09:05 +08:00
|
|
|
*/
|
|
|
|
void (*pre_enable)(struct drm_bridge *bridge);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @enable:
|
|
|
|
*
|
|
|
|
* This callback should enable the bridge. It is called right after
|
|
|
|
* the preceding element in the display pipe is enabled. If the
|
|
|
|
* preceding element is a bridge this means it's called after that
|
2017-01-02 16:17:26 +08:00
|
|
|
* bridge's @enable function. If the preceding element is a
|
|
|
|
* &drm_encoder it's called right after the encoder's
|
|
|
|
* &drm_encoder_helper_funcs.enable, &drm_encoder_helper_funcs.commit or
|
|
|
|
* &drm_encoder_helper_funcs.dpms hook.
|
2016-09-01 00:09:05 +08:00
|
|
|
*
|
|
|
|
* The bridge can assume that the display pipe (i.e. clocks and timing
|
|
|
|
* signals) feeding it is running when this callback is called. This
|
|
|
|
* callback must enable the display link feeding the next bridge in the
|
|
|
|
* chain if there is one.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @enable callback is optional.
|
2021-07-10 16:42:40 +08:00
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
*
|
|
|
|
* This is deprecated, do not use!
|
|
|
|
* New drivers shall use &drm_bridge_funcs.atomic_enable.
|
2016-09-01 00:09:05 +08:00
|
|
|
*/
|
|
|
|
void (*enable)(struct drm_bridge *bridge);
|
2019-06-12 00:08:17 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_pre_enable:
|
|
|
|
*
|
|
|
|
* This callback should enable the bridge. It is called right before
|
|
|
|
* the preceding element in the display pipe is enabled. If the
|
|
|
|
* preceding element is a bridge this means it's called before that
|
|
|
|
* bridge's @atomic_pre_enable or @pre_enable function. If the preceding
|
|
|
|
* element is a &drm_encoder it's called right before the encoder's
|
|
|
|
* &drm_encoder_helper_funcs.atomic_enable hook.
|
|
|
|
*
|
|
|
|
* The display pipe (i.e. clocks and timing signals) feeding this bridge
|
|
|
|
* will not yet be running when this callback is called. The bridge must
|
|
|
|
* not enable the display link feeding the next bridge in the chain (if
|
|
|
|
* there is one) when this callback is called.
|
|
|
|
*
|
|
|
|
* The @atomic_pre_enable callback is optional.
|
|
|
|
*/
|
|
|
|
void (*atomic_pre_enable)(struct drm_bridge *bridge,
|
2020-01-28 21:55:06 +08:00
|
|
|
struct drm_bridge_state *old_bridge_state);
|
2019-06-12 00:08:17 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_enable:
|
|
|
|
*
|
|
|
|
* This callback should enable the bridge. It is called right after
|
|
|
|
* the preceding element in the display pipe is enabled. If the
|
|
|
|
* preceding element is a bridge this means it's called after that
|
|
|
|
* bridge's @atomic_enable or @enable function. If the preceding element
|
|
|
|
* is a &drm_encoder it's called right after the encoder's
|
|
|
|
* &drm_encoder_helper_funcs.atomic_enable hook.
|
|
|
|
*
|
|
|
|
* The bridge can assume that the display pipe (i.e. clocks and timing
|
|
|
|
* signals) feeding it is running when this callback is called. This
|
|
|
|
* callback must enable the display link feeding the next bridge in the
|
|
|
|
* chain if there is one.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @atomic_enable callback is optional.
|
2019-06-12 00:08:17 +08:00
|
|
|
*/
|
|
|
|
void (*atomic_enable)(struct drm_bridge *bridge,
|
2020-01-28 21:55:06 +08:00
|
|
|
struct drm_bridge_state *old_bridge_state);
|
2019-06-12 00:08:17 +08:00
|
|
|
/**
|
|
|
|
* @atomic_disable:
|
|
|
|
*
|
|
|
|
* This callback should disable the bridge. It is called right before
|
|
|
|
* the preceding element in the display pipe is disabled. If the
|
|
|
|
* preceding element is a bridge this means it's called before that
|
|
|
|
* bridge's @atomic_disable or @disable vfunc. If the preceding element
|
|
|
|
* is a &drm_encoder it's called right before the
|
|
|
|
* &drm_encoder_helper_funcs.atomic_disable hook.
|
|
|
|
*
|
|
|
|
* The bridge can assume that the display pipe (i.e. clocks and timing
|
|
|
|
* signals) feeding it is still running when this callback is called.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @atomic_disable callback is optional.
|
2019-06-12 00:08:17 +08:00
|
|
|
*/
|
|
|
|
void (*atomic_disable)(struct drm_bridge *bridge,
|
2020-01-28 21:55:06 +08:00
|
|
|
struct drm_bridge_state *old_bridge_state);
|
2019-06-12 00:08:17 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_post_disable:
|
|
|
|
*
|
|
|
|
* This callback should disable the bridge. It is called right after the
|
|
|
|
* preceding element in the display pipe is disabled. If the preceding
|
|
|
|
* element is a bridge this means it's called after that bridge's
|
|
|
|
* @atomic_post_disable or @post_disable function. If the preceding
|
|
|
|
* element is a &drm_encoder it's called right after the encoder's
|
|
|
|
* &drm_encoder_helper_funcs.atomic_disable hook.
|
|
|
|
*
|
|
|
|
* The bridge must assume that the display pipe (i.e. clocks and timing
|
|
|
|
* signals) feeding it is no longer running when this callback is
|
|
|
|
* called.
|
|
|
|
*
|
2019-08-22 07:55:02 +08:00
|
|
|
* The @atomic_post_disable callback is optional.
|
2019-06-12 00:08:17 +08:00
|
|
|
*/
|
|
|
|
void (*atomic_post_disable)(struct drm_bridge *bridge,
|
2020-01-28 21:55:06 +08:00
|
|
|
struct drm_bridge_state *old_bridge_state);
|
2020-01-28 21:55:03 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_duplicate_state:
|
|
|
|
*
|
|
|
|
* Duplicate the current bridge state object (which is guaranteed to be
|
|
|
|
* non-NULL).
|
|
|
|
*
|
2020-02-26 19:24:25 +08:00
|
|
|
* The atomic_duplicate_state hook is mandatory if the bridge
|
|
|
|
* implements any of the atomic hooks, and should be left unassigned
|
|
|
|
* otherwise. For bridges that don't subclass &drm_bridge_state, the
|
|
|
|
* drm_atomic_helper_bridge_duplicate_state() helper function shall be
|
|
|
|
* used to implement this hook.
|
2020-01-28 21:55:03 +08:00
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* A valid drm_bridge_state object or NULL if the allocation fails.
|
|
|
|
*/
|
|
|
|
struct drm_bridge_state *(*atomic_duplicate_state)(struct drm_bridge *bridge);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_destroy_state:
|
|
|
|
*
|
|
|
|
* Destroy a bridge state object previously allocated by
|
|
|
|
* &drm_bridge_funcs.atomic_duplicate_state().
|
|
|
|
*
|
2020-02-26 19:24:25 +08:00
|
|
|
* The atomic_destroy_state hook is mandatory if the bridge implements
|
|
|
|
* any of the atomic hooks, and should be left unassigned otherwise.
|
|
|
|
* For bridges that don't subclass &drm_bridge_state, the
|
|
|
|
* drm_atomic_helper_bridge_destroy_state() helper function shall be
|
|
|
|
* used to implement this hook.
|
2020-01-28 21:55:03 +08:00
|
|
|
*/
|
|
|
|
void (*atomic_destroy_state)(struct drm_bridge *bridge,
|
|
|
|
struct drm_bridge_state *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
|
|
|
/**
|
|
|
|
* @atomic_get_output_bus_fmts:
|
|
|
|
*
|
|
|
|
* Return the supported bus formats on the output end of a bridge.
|
|
|
|
* The returned array must be allocated with kmalloc() and will be
|
|
|
|
* freed by the caller. If the allocation fails, NULL should be
|
|
|
|
* returned. num_output_fmts must be set to the returned array size.
|
|
|
|
* Formats listed in the returned array should be listed in decreasing
|
|
|
|
* preference order (the core will try all formats until it finds one
|
|
|
|
* that works).
|
|
|
|
*
|
|
|
|
* This method is only called on the last element of the bridge chain
|
|
|
|
* as part of the bus format negotiation process that happens in
|
|
|
|
* &drm_atomic_bridge_chain_select_bus_fmts().
|
|
|
|
* This method is optional. When not implemented, the core will
|
|
|
|
* fall back to &drm_connector.display_info.bus_formats[0] if
|
|
|
|
* &drm_connector.display_info.num_bus_formats > 0,
|
|
|
|
* or to MEDIA_BUS_FMT_FIXED otherwise.
|
|
|
|
*/
|
|
|
|
u32 *(*atomic_get_output_bus_fmts)(struct drm_bridge *bridge,
|
|
|
|
struct drm_bridge_state *bridge_state,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state,
|
|
|
|
unsigned int *num_output_fmts);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @atomic_get_input_bus_fmts:
|
|
|
|
*
|
|
|
|
* Return the supported bus formats on the input end of a bridge for
|
|
|
|
* a specific output bus format.
|
|
|
|
*
|
|
|
|
* The returned array must be allocated with kmalloc() and will be
|
|
|
|
* freed by the caller. If the allocation fails, NULL should be
|
|
|
|
* returned. num_output_fmts must be set to the returned array size.
|
|
|
|
* Formats listed in the returned array should be listed in decreasing
|
|
|
|
* preference order (the core will try all formats until it finds one
|
|
|
|
* that works). When the format is not supported NULL should be
|
2020-02-18 23:15:03 +08:00
|
|
|
* returned and num_output_fmts should be set to 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
|
|
|
*
|
|
|
|
* This method is called on all elements of the bridge chain as part of
|
|
|
|
* the bus format negotiation process that happens in
|
2020-02-18 23:15:03 +08:00
|
|
|
* drm_atomic_bridge_chain_select_bus_fmts().
|
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
|
|
|
* This method is optional. When not implemented, the core will bypass
|
|
|
|
* bus format negotiation on this element of the bridge without
|
|
|
|
* failing, and the previous element in the chain will be passed
|
|
|
|
* MEDIA_BUS_FMT_FIXED as its output bus format.
|
|
|
|
*
|
|
|
|
* Bridge drivers that need to support being linked to bridges that are
|
|
|
|
* not supporting bus format negotiation should handle the
|
|
|
|
* output_fmt == MEDIA_BUS_FMT_FIXED case appropriately, by selecting a
|
|
|
|
* sensible default value or extracting this information from somewhere
|
|
|
|
* else (FW property, &drm_display_mode, &drm_display_info, ...)
|
|
|
|
*
|
|
|
|
* Note: Even if input format selection on the first bridge has no
|
|
|
|
* impact on the negotiation process (bus format negotiation stops once
|
|
|
|
* we reach the first element of the chain), drivers are expected to
|
|
|
|
* return accurate input formats as the input format may be used to
|
|
|
|
* configure the CRTC output appropriately.
|
|
|
|
*/
|
|
|
|
u32 *(*atomic_get_input_bus_fmts)(struct drm_bridge *bridge,
|
|
|
|
struct drm_bridge_state *bridge_state,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state,
|
|
|
|
u32 output_fmt,
|
|
|
|
unsigned int *num_input_fmts);
|
|
|
|
|
2020-01-28 21:55:07 +08:00
|
|
|
/**
|
|
|
|
* @atomic_check:
|
|
|
|
*
|
|
|
|
* This method is responsible for checking bridge state correctness.
|
|
|
|
* It can also check the state of the surrounding components in chain
|
|
|
|
* to make sure the whole pipeline can work properly.
|
|
|
|
*
|
|
|
|
* &drm_bridge_funcs.atomic_check() hooks are called in reverse
|
|
|
|
* order (from the last to the first bridge).
|
|
|
|
*
|
|
|
|
* This method is optional. &drm_bridge_funcs.mode_fixup() is not
|
|
|
|
* called when &drm_bridge_funcs.atomic_check() is implemented, so only
|
|
|
|
* one of them should be provided.
|
|
|
|
*
|
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
|
|
|
* If drivers need to tweak &drm_bridge_state.input_bus_cfg.flags or
|
2020-07-15 13:23:44 +08:00
|
|
|
* &drm_bridge_state.output_bus_cfg.flags it should happen in
|
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
|
|
|
* this function. By default the &drm_bridge_state.output_bus_cfg.flags
|
|
|
|
* field is set to the next bridge
|
|
|
|
* &drm_bridge_state.input_bus_cfg.flags value or
|
|
|
|
* &drm_connector.display_info.bus_flags if the bridge is the last
|
|
|
|
* element in the chain.
|
|
|
|
*
|
2020-01-28 21:55:07 +08:00
|
|
|
* RETURNS:
|
|
|
|
* zero if the check passed, a negative error code otherwise.
|
|
|
|
*/
|
|
|
|
int (*atomic_check)(struct drm_bridge *bridge,
|
|
|
|
struct drm_bridge_state *bridge_state,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state);
|
|
|
|
|
2020-01-28 21:55:03 +08:00
|
|
|
/**
|
|
|
|
* @atomic_reset:
|
|
|
|
*
|
|
|
|
* Reset the bridge to a predefined state (or retrieve its current
|
|
|
|
* state) and return a &drm_bridge_state object matching this state.
|
|
|
|
* This function is called at attach time.
|
|
|
|
*
|
|
|
|
* The atomic_reset hook is mandatory if the bridge implements any of
|
2020-02-26 19:24:25 +08:00
|
|
|
* the atomic hooks, and should be left unassigned otherwise. For
|
|
|
|
* bridges that don't subclass &drm_bridge_state, the
|
|
|
|
* drm_atomic_helper_bridge_reset() helper function shall be used to
|
|
|
|
* implement this hook.
|
2020-01-28 21:55:03 +08:00
|
|
|
*
|
|
|
|
* Note that the atomic_reset() semantics is not exactly matching the
|
|
|
|
* reset() semantics found on other components (connector, plane, ...).
|
2020-02-18 23:15:03 +08:00
|
|
|
*
|
|
|
|
* 1. The reset operation happens when the bridge is attached, not when
|
2020-01-28 21:55:03 +08:00
|
|
|
* drm_mode_config_reset() is called
|
2020-02-18 23:15:03 +08:00
|
|
|
* 2. It's meant to be used exclusively on bridges that have been
|
2020-01-28 21:55:03 +08:00
|
|
|
* converted to the ATOMIC API
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* A valid drm_bridge_state object in case of success, an ERR_PTR()
|
|
|
|
* giving the reason of the failure otherwise.
|
|
|
|
*/
|
|
|
|
struct drm_bridge_state *(*atomic_reset)(struct drm_bridge *bridge);
|
2020-02-26 19:24:27 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @detect:
|
|
|
|
*
|
|
|
|
* Check if anything is attached to the bridge output.
|
|
|
|
*
|
|
|
|
* This callback is optional, if not implemented the bridge will be
|
|
|
|
* considered as always having a component attached to its output.
|
|
|
|
* Bridges that implement this callback shall set the
|
|
|
|
* DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* drm_connector_status indicating the bridge output status.
|
|
|
|
*/
|
|
|
|
enum drm_connector_status (*detect)(struct drm_bridge *bridge);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @get_modes:
|
|
|
|
*
|
|
|
|
* Fill all modes currently valid for the sink into the &drm_connector
|
|
|
|
* with drm_mode_probed_add().
|
|
|
|
*
|
|
|
|
* The @get_modes callback is mostly intended to support non-probeable
|
|
|
|
* displays such as many fixed panels. Bridges that support reading
|
|
|
|
* EDID shall leave @get_modes unimplemented and implement the
|
|
|
|
* &drm_bridge_funcs->get_edid callback instead.
|
|
|
|
*
|
|
|
|
* This callback is optional. Bridges that implement it shall set the
|
|
|
|
* DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
|
|
|
|
*
|
|
|
|
* The connector parameter shall be used for the sole purpose of
|
|
|
|
* filling modes, and shall not be stored internally by bridge drivers
|
|
|
|
* for future usage.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* The number of modes added by calling drm_mode_probed_add().
|
|
|
|
*/
|
|
|
|
int (*get_modes)(struct drm_bridge *bridge,
|
|
|
|
struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @get_edid:
|
|
|
|
*
|
|
|
|
* Read and parse the EDID data of the connected display.
|
|
|
|
*
|
|
|
|
* The @get_edid callback is the preferred way of reporting mode
|
|
|
|
* information for a display connected to the bridge output. Bridges
|
|
|
|
* that support reading EDID shall implement this callback and leave
|
|
|
|
* the @get_modes callback unimplemented.
|
|
|
|
*
|
|
|
|
* The caller of this operation shall first verify the output
|
|
|
|
* connection status and refrain from reading EDID from a disconnected
|
|
|
|
* output.
|
|
|
|
*
|
|
|
|
* This callback is optional. Bridges that implement it shall set the
|
|
|
|
* DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
|
|
|
|
*
|
|
|
|
* The connector parameter shall be used for the sole purpose of EDID
|
|
|
|
* retrieval and parsing, and shall not be stored internally by bridge
|
|
|
|
* drivers for future usage.
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
*
|
|
|
|
* An edid structure newly allocated with kmalloc() (or similar) on
|
|
|
|
* success, or NULL otherwise. The caller is responsible for freeing
|
|
|
|
* the returned edid structure with kfree().
|
|
|
|
*/
|
|
|
|
struct edid *(*get_edid)(struct drm_bridge *bridge,
|
|
|
|
struct drm_connector *connector);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @hpd_notify:
|
|
|
|
*
|
|
|
|
* Notify the bridge of hot plug detection.
|
|
|
|
*
|
|
|
|
* This callback is optional, it may be implemented by bridges that
|
|
|
|
* need to be notified of display connection or disconnection for
|
|
|
|
* internal reasons. One use case is to reset the internal state of CEC
|
|
|
|
* controllers for HDMI bridges.
|
|
|
|
*/
|
|
|
|
void (*hpd_notify)(struct drm_bridge *bridge,
|
|
|
|
enum drm_connector_status status);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @hpd_enable:
|
|
|
|
*
|
|
|
|
* Enable hot plug detection. From now on the bridge shall call
|
|
|
|
* drm_bridge_hpd_notify() each time a change is detected in the output
|
|
|
|
* connection status, until hot plug detection gets disabled with
|
|
|
|
* @hpd_disable.
|
|
|
|
*
|
|
|
|
* This callback is optional and shall only be implemented by bridges
|
|
|
|
* that support hot-plug notification without polling. Bridges that
|
|
|
|
* implement it shall also implement the @hpd_disable callback and set
|
|
|
|
* the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
|
|
|
|
*/
|
|
|
|
void (*hpd_enable)(struct drm_bridge *bridge);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @hpd_disable:
|
|
|
|
*
|
|
|
|
* Disable hot plug detection. Once this function returns the bridge
|
|
|
|
* shall not call drm_bridge_hpd_notify() when a change in the output
|
|
|
|
* connection status occurs.
|
|
|
|
*
|
|
|
|
* This callback is optional and shall only be implemented by bridges
|
|
|
|
* that support hot-plug notification without polling. Bridges that
|
|
|
|
* implement it shall also implement the @hpd_enable callback and set
|
|
|
|
* the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
|
|
|
|
*/
|
|
|
|
void (*hpd_disable)(struct drm_bridge *bridge);
|
2022-02-05 08:13:41 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @debugfs_init:
|
|
|
|
*
|
|
|
|
* Allows bridges to create bridge-specific debugfs files.
|
|
|
|
*/
|
|
|
|
void (*debugfs_init)(struct drm_bridge *bridge, struct dentry *root);
|
2016-09-01 00:09:05 +08:00
|
|
|
};
|
|
|
|
|
2018-01-12 15:48:52 +08:00
|
|
|
/**
|
|
|
|
* struct drm_bridge_timings - timing information for the bridge
|
|
|
|
*/
|
|
|
|
struct drm_bridge_timings {
|
|
|
|
/**
|
2018-09-05 13:21:08 +08:00
|
|
|
* @input_bus_flags:
|
2018-01-12 15:48:52 +08:00
|
|
|
*
|
2018-09-05 13:21:08 +08:00
|
|
|
* Tells what additional settings for the pixel data on the bus
|
|
|
|
* this bridge requires (like pixel signal polarity). See also
|
|
|
|
* &drm_display_info->bus_flags.
|
2018-01-12 15:48:52 +08:00
|
|
|
*/
|
2018-09-05 13:21:08 +08:00
|
|
|
u32 input_bus_flags;
|
2018-01-12 15:48:52 +08:00
|
|
|
/**
|
|
|
|
* @setup_time_ps:
|
|
|
|
*
|
|
|
|
* Defines the time in picoseconds the input data lines must be
|
|
|
|
* stable before the clock edge.
|
|
|
|
*/
|
|
|
|
u32 setup_time_ps;
|
|
|
|
/**
|
|
|
|
* @hold_time_ps:
|
|
|
|
*
|
|
|
|
* Defines the time in picoseconds taken for the bridge to sample the
|
|
|
|
* input signal after the clock edge.
|
|
|
|
*/
|
|
|
|
u32 hold_time_ps;
|
2019-03-05 05:05:34 +08:00
|
|
|
/**
|
|
|
|
* @dual_link:
|
|
|
|
*
|
|
|
|
* True if the bus operates in dual-link mode. The exact meaning is
|
|
|
|
* dependent on the bus type. For LVDS buses, this indicates that even-
|
|
|
|
* and odd-numbered pixels are received on separate links.
|
|
|
|
*/
|
|
|
|
bool dual_link;
|
2018-01-12 15:48:52 +08:00
|
|
|
};
|
|
|
|
|
2020-02-26 19:24:27 +08:00
|
|
|
/**
|
|
|
|
* enum drm_bridge_ops - Bitmask of operations supported by the bridge
|
|
|
|
*/
|
|
|
|
enum drm_bridge_ops {
|
|
|
|
/**
|
|
|
|
* @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
|
|
|
|
* its output. Bridges that set this flag shall implement the
|
|
|
|
* &drm_bridge_funcs->detect callback.
|
|
|
|
*/
|
|
|
|
DRM_BRIDGE_OP_DETECT = BIT(0),
|
|
|
|
/**
|
|
|
|
* @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
|
|
|
|
* connected to its output. Bridges that set this flag shall implement
|
|
|
|
* the &drm_bridge_funcs->get_edid callback.
|
|
|
|
*/
|
|
|
|
DRM_BRIDGE_OP_EDID = BIT(1),
|
|
|
|
/**
|
|
|
|
* @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
|
|
|
|
* without requiring polling. Bridges that set this flag shall
|
|
|
|
* implement the &drm_bridge_funcs->hpd_enable and
|
|
|
|
* &drm_bridge_funcs->hpd_disable callbacks if they support enabling
|
|
|
|
* and disabling hot-plug detection dynamically.
|
|
|
|
*/
|
|
|
|
DRM_BRIDGE_OP_HPD = BIT(2),
|
|
|
|
/**
|
|
|
|
* @DRM_BRIDGE_OP_MODES: The bridge can retrieve the modes supported
|
|
|
|
* by the display at its output. This does not include reading EDID
|
|
|
|
* which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
|
|
|
|
* this flag shall implement the &drm_bridge_funcs->get_modes callback.
|
|
|
|
*/
|
|
|
|
DRM_BRIDGE_OP_MODES = BIT(3),
|
|
|
|
};
|
|
|
|
|
2016-09-01 00:09:05 +08:00
|
|
|
/**
|
|
|
|
* struct drm_bridge - central DRM bridge control structure
|
|
|
|
*/
|
|
|
|
struct drm_bridge {
|
2020-01-28 21:55:03 +08:00
|
|
|
/** @base: inherit from &drm_private_object */
|
|
|
|
struct drm_private_obj base;
|
2018-06-07 03:04:29 +08:00
|
|
|
/** @dev: DRM device this bridge belongs to */
|
2016-09-01 00:09:05 +08:00
|
|
|
struct drm_device *dev;
|
2018-06-07 03:04:29 +08:00
|
|
|
/** @encoder: encoder to which this bridge is connected */
|
2016-09-01 00:09:05 +08:00
|
|
|
struct drm_encoder *encoder;
|
2019-12-03 22:15:08 +08:00
|
|
|
/** @chain_node: used to form a bridge chain */
|
|
|
|
struct list_head chain_node;
|
2016-09-01 00:09:05 +08:00
|
|
|
#ifdef CONFIG_OF
|
2018-06-07 03:04:29 +08:00
|
|
|
/** @of_node: device node pointer to the bridge */
|
2016-09-01 00:09:05 +08:00
|
|
|
struct device_node *of_node;
|
|
|
|
#endif
|
2018-06-07 03:04:29 +08:00
|
|
|
/** @list: to keep track of all added bridges */
|
2016-09-01 00:09:05 +08:00
|
|
|
struct list_head list;
|
2018-06-07 03:04:29 +08:00
|
|
|
/**
|
|
|
|
* @timings:
|
|
|
|
*
|
|
|
|
* the timing specification for the bridge, if any (may be NULL)
|
|
|
|
*/
|
2018-01-12 15:48:52 +08:00
|
|
|
const struct drm_bridge_timings *timings;
|
2018-06-07 03:04:29 +08:00
|
|
|
/** @funcs: control functions */
|
2016-09-01 00:09:05 +08:00
|
|
|
const struct drm_bridge_funcs *funcs;
|
2018-06-07 03:04:29 +08:00
|
|
|
/** @driver_private: pointer to the bridge driver's internal context */
|
2016-09-01 00:09:05 +08:00
|
|
|
void *driver_private;
|
2020-02-26 19:24:27 +08:00
|
|
|
/** @ops: bitmask of operations supported by the bridge */
|
|
|
|
enum drm_bridge_ops ops;
|
|
|
|
/**
|
|
|
|
* @type: Type of the connection at the bridge output
|
|
|
|
* (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
|
|
|
|
* identifies the type of connected display.
|
|
|
|
*/
|
|
|
|
int type;
|
2020-02-26 19:24:28 +08:00
|
|
|
/**
|
|
|
|
* @interlace_allowed: Indicate that the bridge can handle interlaced
|
|
|
|
* modes.
|
|
|
|
*/
|
|
|
|
bool interlace_allowed;
|
drm/bridge: Introduce pre_enable_prev_first to alter bridge init order
DSI sink devices typically want the DSI host powered up and configured
before they are powered up. pre_enable is the place this would normally
happen, but they are called in reverse order from panel/connector towards
the encoder, which is the "wrong" order.
Add a new flag pre_enable_prev_first that any bridge can set
to swap the order of pre_enable (and post_disable) for that and the
immediately previous bridge.
Should the immediately previous bridge also set the
pre_enable_prev_first flag, the previous bridge to that will be called
before either of those which requested pre_enable_prev_first.
eg:
- Panel
- Bridge 1
- Bridge 2 pre_enable_prev_first
- Bridge 3
- Bridge 4 pre_enable_prev_first
- Bridge 5 pre_enable_prev_first
- Bridge 6
- Encoder
Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3,
Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://lore.kernel.org/r/20221205173328.1395350-5-dave.stevenson@raspberrypi.com
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-12-06 01:33:26 +08:00
|
|
|
/**
|
|
|
|
* @pre_enable_prev_first: The bridge requires that the prev
|
|
|
|
* bridge @pre_enable function is called before its @pre_enable,
|
|
|
|
* and conversely for post_disable. This is most frequently a
|
|
|
|
* requirement for DSI devices which need the host to be initialised
|
|
|
|
* before the peripheral.
|
|
|
|
*/
|
|
|
|
bool pre_enable_prev_first;
|
2020-02-26 19:24:27 +08:00
|
|
|
/**
|
|
|
|
* @ddc: Associated I2C adapter for DDC access, if any.
|
|
|
|
*/
|
|
|
|
struct i2c_adapter *ddc;
|
|
|
|
/** private: */
|
|
|
|
/**
|
|
|
|
* @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
|
|
|
|
*/
|
|
|
|
struct mutex hpd_mutex;
|
|
|
|
/**
|
|
|
|
* @hpd_cb: Hot plug detection callback, registered with
|
|
|
|
* drm_bridge_hpd_enable().
|
|
|
|
*/
|
|
|
|
void (*hpd_cb)(void *data, enum drm_connector_status status);
|
|
|
|
/**
|
|
|
|
* @hpd_data: Private data passed to the Hot plug detection callback
|
|
|
|
* @hpd_cb.
|
|
|
|
*/
|
|
|
|
void *hpd_data;
|
2016-09-01 00:09:05 +08:00
|
|
|
};
|
|
|
|
|
2020-01-28 21:55:03 +08:00
|
|
|
static inline struct drm_bridge *
|
|
|
|
drm_priv_to_bridge(struct drm_private_obj *priv)
|
|
|
|
{
|
|
|
|
return container_of(priv, struct drm_bridge, base);
|
|
|
|
}
|
|
|
|
|
2017-07-03 16:42:17 +08:00
|
|
|
void drm_bridge_add(struct drm_bridge *bridge);
|
2022-05-11 03:29:43 +08:00
|
|
|
int devm_drm_bridge_add(struct device *dev, struct drm_bridge *bridge);
|
2016-09-01 00:09:05 +08:00
|
|
|
void drm_bridge_remove(struct drm_bridge *bridge);
|
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);
|
2016-09-01 00:09:05 +08:00
|
|
|
|
2021-09-23 20:47:57 +08:00
|
|
|
#ifdef CONFIG_OF
|
|
|
|
struct drm_bridge *of_drm_find_bridge(struct device_node *np);
|
|
|
|
#else
|
|
|
|
static inline struct drm_bridge *of_drm_find_bridge(struct device_node *np)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-12-03 22:15:06 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_get_next_bridge() - Get the next bridge in the chain
|
|
|
|
* @bridge: bridge object
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* the next bridge in the chain after @bridge, or NULL if @bridge is the last.
|
|
|
|
*/
|
|
|
|
static inline struct drm_bridge *
|
|
|
|
drm_bridge_get_next_bridge(struct drm_bridge *bridge)
|
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
if (list_is_last(&bridge->chain_node, &bridge->encoder->bridge_chain))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return list_next_entry(bridge, chain_node);
|
2019-12-03 22:15:06 +08:00
|
|
|
}
|
|
|
|
|
2019-12-03 22:15:10 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_get_prev_bridge() - Get the previous bridge in the chain
|
|
|
|
* @bridge: bridge object
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* the previous bridge in the chain, or NULL if @bridge is the first.
|
|
|
|
*/
|
|
|
|
static inline struct drm_bridge *
|
|
|
|
drm_bridge_get_prev_bridge(struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
if (list_is_first(&bridge->chain_node, &bridge->encoder->bridge_chain))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return list_prev_entry(bridge, chain_node);
|
|
|
|
}
|
|
|
|
|
2019-12-03 22:15:07 +08:00
|
|
|
/**
|
|
|
|
* drm_bridge_chain_get_first_bridge() - Get the first bridge in the chain
|
|
|
|
* @encoder: encoder object
|
|
|
|
*
|
|
|
|
* RETURNS:
|
|
|
|
* the first bridge in the chain, or NULL if @encoder has no bridge attached
|
|
|
|
* to it.
|
|
|
|
*/
|
|
|
|
static inline struct drm_bridge *
|
|
|
|
drm_bridge_chain_get_first_bridge(struct drm_encoder *encoder)
|
|
|
|
{
|
2019-12-03 22:15:08 +08:00
|
|
|
return list_first_entry_or_null(&encoder->bridge_chain,
|
|
|
|
struct drm_bridge, chain_node);
|
2019-12-03 22:15:07 +08:00
|
|
|
}
|
|
|
|
|
2019-12-03 22:15:09 +08:00
|
|
|
/**
|
|
|
|
* drm_for_each_bridge_in_chain() - Iterate over all bridges present in a chain
|
|
|
|
* @encoder: the encoder to iterate bridges on
|
|
|
|
* @bridge: a bridge pointer updated to point to the current bridge at each
|
|
|
|
* iteration
|
|
|
|
*
|
|
|
|
* Iterate over all bridges present in the bridge chain attached to @encoder.
|
|
|
|
*/
|
|
|
|
#define drm_for_each_bridge_in_chain(encoder, bridge) \
|
|
|
|
list_for_each_entry(bridge, &(encoder)->bridge_chain, chain_node)
|
|
|
|
|
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);
|
|
|
|
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);
|
|
|
|
void drm_bridge_chain_mode_set(struct drm_bridge *bridge,
|
|
|
|
const struct drm_display_mode *mode,
|
|
|
|
const struct drm_display_mode *adjusted_mode);
|
2016-09-01 00:09:05 +08:00
|
|
|
|
2020-01-28 21:55:07 +08:00
|
|
|
int drm_atomic_bridge_chain_check(struct drm_bridge *bridge,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state);
|
2019-12-03 22:15:05 +08:00
|
|
|
void drm_atomic_bridge_chain_disable(struct drm_bridge *bridge,
|
|
|
|
struct drm_atomic_state *state);
|
|
|
|
void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
|
|
|
|
struct drm_atomic_state *state);
|
|
|
|
void drm_atomic_bridge_chain_pre_enable(struct drm_bridge *bridge,
|
|
|
|
struct drm_atomic_state *state);
|
|
|
|
void drm_atomic_bridge_chain_enable(struct drm_bridge *bridge,
|
2019-06-12 00:08:17 +08:00
|
|
|
struct drm_atomic_state *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
|
|
|
u32 *
|
|
|
|
drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
|
|
|
|
struct drm_bridge_state *bridge_state,
|
|
|
|
struct drm_crtc_state *crtc_state,
|
|
|
|
struct drm_connector_state *conn_state,
|
|
|
|
u32 output_fmt,
|
|
|
|
unsigned int *num_input_fmts);
|
|
|
|
|
2020-02-26 19:24:27 +08:00
|
|
|
enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge);
|
|
|
|
int drm_bridge_get_modes(struct drm_bridge *bridge,
|
|
|
|
struct drm_connector *connector);
|
|
|
|
struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
|
|
|
|
struct drm_connector *connector);
|
|
|
|
void drm_bridge_hpd_enable(struct drm_bridge *bridge,
|
|
|
|
void (*cb)(void *data,
|
|
|
|
enum drm_connector_status status),
|
|
|
|
void *data);
|
|
|
|
void drm_bridge_hpd_disable(struct drm_bridge *bridge);
|
|
|
|
void drm_bridge_hpd_notify(struct drm_bridge *bridge,
|
|
|
|
enum drm_connector_status status);
|
|
|
|
|
2017-06-03 04:25:14 +08:00
|
|
|
#ifdef CONFIG_DRM_PANEL_BRIDGE
|
2022-06-09 15:27:23 +08:00
|
|
|
bool drm_bridge_is_panel(const struct drm_bridge *bridge);
|
drm/bridge: panel: Infer connector type from panel by default
The drm panel bridge creates a connector using a connector type
explicitly passed by the display controller or bridge driver that
instantiates the panel bridge. Now that drm_panel reports its connector
type, we can use it to avoid passing an explicit (and often incorrect)
connector type to drm_panel_bridge_add() and
devm_drm_panel_bridge_add().
Several drivers report incorrect or unknown connector types to
userspace. Reporting a different type may result in a breakage. For that
reason, rename (devm_)drm_panel_bridge_add() to
(devm_)drm_panel_bridge_add_typed(), and add new
(devm_)drm_panel_bridge_add() functions that use the panel connector
type. Update all callers of (devm_)drm_panel_bridge_add() to the _typed
function, they will be converted one by one after testing.
The panel drivers have been updated with the following Coccinelle
semantic patch, with manual inspection and fixes to indentation.
@@
expression bridge;
expression dev;
expression panel;
identifier type;
@@
(
-bridge = drm_panel_bridge_add(panel, type);
+bridge = drm_panel_bridge_add_typed(panel, type);
|
-bridge = devm_drm_panel_bridge_add(dev, panel, type);
+bridge = devm_drm_panel_bridge_add_typed(dev, panel, type);
)
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190904132804.29680-3-laurent.pinchart@ideasonboard.com
2019-09-04 21:28:04 +08:00
|
|
|
struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel);
|
|
|
|
struct drm_bridge *drm_panel_bridge_add_typed(struct drm_panel *panel,
|
|
|
|
u32 connector_type);
|
2017-06-03 04:25:14 +08:00
|
|
|
void drm_panel_bridge_remove(struct drm_bridge *bridge);
|
2022-06-09 15:27:23 +08:00
|
|
|
int drm_panel_bridge_set_orientation(struct drm_connector *connector,
|
|
|
|
struct drm_bridge *bridge);
|
2017-07-19 05:05:06 +08:00
|
|
|
struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
|
drm/bridge: panel: Infer connector type from panel by default
The drm panel bridge creates a connector using a connector type
explicitly passed by the display controller or bridge driver that
instantiates the panel bridge. Now that drm_panel reports its connector
type, we can use it to avoid passing an explicit (and often incorrect)
connector type to drm_panel_bridge_add() and
devm_drm_panel_bridge_add().
Several drivers report incorrect or unknown connector types to
userspace. Reporting a different type may result in a breakage. For that
reason, rename (devm_)drm_panel_bridge_add() to
(devm_)drm_panel_bridge_add_typed(), and add new
(devm_)drm_panel_bridge_add() functions that use the panel connector
type. Update all callers of (devm_)drm_panel_bridge_add() to the _typed
function, they will be converted one by one after testing.
The panel drivers have been updated with the following Coccinelle
semantic patch, with manual inspection and fixes to indentation.
@@
expression bridge;
expression dev;
expression panel;
identifier type;
@@
(
-bridge = drm_panel_bridge_add(panel, type);
+bridge = drm_panel_bridge_add_typed(panel, type);
|
-bridge = devm_drm_panel_bridge_add(dev, panel, type);
+bridge = devm_drm_panel_bridge_add_typed(dev, panel, type);
)
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190904132804.29680-3-laurent.pinchart@ideasonboard.com
2019-09-04 21:28:04 +08:00
|
|
|
struct drm_panel *panel);
|
|
|
|
struct drm_bridge *devm_drm_panel_bridge_add_typed(struct device *dev,
|
|
|
|
struct drm_panel *panel,
|
|
|
|
u32 connector_type);
|
2022-07-12 01:38:40 +08:00
|
|
|
struct drm_bridge *drmm_panel_bridge_add(struct drm_device *drm,
|
|
|
|
struct drm_panel *panel);
|
2021-09-29 02:13:33 +08:00
|
|
|
struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
|
2022-06-09 15:27:23 +08:00
|
|
|
#else
|
|
|
|
static inline bool drm_bridge_is_panel(const struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int drm_panel_bridge_set_orientation(struct drm_connector *connector,
|
|
|
|
struct drm_bridge *bridge)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2021-09-29 02:13:33 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
|
2021-09-10 21:09:39 +08:00
|
|
|
struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct device_node *node,
|
|
|
|
u32 port, u32 endpoint);
|
2022-07-12 01:38:41 +08:00
|
|
|
struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm, struct device_node *node,
|
|
|
|
u32 port, u32 endpoint);
|
2021-09-29 02:13:33 +08:00
|
|
|
#else
|
|
|
|
static inline struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
|
|
|
|
struct device_node *node,
|
|
|
|
u32 port,
|
|
|
|
u32 endpoint)
|
|
|
|
{
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
}
|
2022-07-16 10:07:41 +08:00
|
|
|
|
|
|
|
static inline struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm,
|
|
|
|
struct device_node *node,
|
|
|
|
u32 port,
|
|
|
|
u32 endpoint)
|
|
|
|
{
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
}
|
2017-06-03 04:25:14 +08:00
|
|
|
#endif
|
|
|
|
|
2016-09-01 00:09:05 +08:00
|
|
|
#endif
|