drm/bridge: Add the necessary bits to support bus format negotiation
authorBoris Brezillon <boris.brezillon@collabora.com>
Tue, 28 Jan 2020 13:55:08 +0000 (14:55 +0100)
committerBoris Brezillon <boris.brezillon@collabora.com>
Fri, 31 Jan 2020 15:39:53 +0000 (16:39 +0100)
commitf32df58acc68b4fae118e00e7fc272b4fb8d5fda
treed26cf8f58fce1675cd8360297c11e1b44766b4f6
parent5061b8a969f7cd40f8d81f76e22a5e4fb13d6665
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
drivers/gpu/drm/drm_atomic_helper.c
drivers/gpu/drm/drm_bridge.c
include/drm/drm_atomic.h
include/drm/drm_atomic_helper.h
include/drm/drm_bridge.h