[PATCH v3 00/21] drm: Add support for bus-format negotiation

[Boris Brezillon]

On Sun, 24 Nov 2019 09:46:41 +0900
Ezequiel Garcia <ezequiel at collabora.com> wrote:

> Hi Boris, Neil,
> 
> On Wed, 2019-10-23 at 17:44 +0200, Boris Brezillon wrote:
> > This patch series aims at adding support for runtime bus-format
> > negotiation between all elements of the
> > 'encoder -> bridges -> connector/display' section of the pipeline.
> > 
> > In order to support that, we need drm bridges to fully take part in the
> > atomic state validation process, which requires adding a
> > drm_bridge_state and a new drm_bridge_funcs.atomic_check() hook.
> > Once those basic building blocks are in place, we can add new hooks to
> > allow bus format negotiation (those are called just before  
> > ->atomic_check()). The bus format selection is done at runtime by  
> > testing all possible combinations across the whole bridge chain until
> > one is reported to work.
> > 
> > Major changes since v2:
> > * Get rid of the dummy bridge embedded in drm_encoder and let encoder
> >   drivers provide their own bridge element
> > * Clarify APIs and improve the doc
> > * Propagate bus flags by default
> > 
> > Major changes since the RFC:
> > 
> > * Add a dummy bridge to the drm_encoder object so that vc4 and exynos
> >   DSI drivers can implement the pre_enable/post_disable hooks instead
> >   of manually setting encoder->bridge to NULL to control the
> >   enable/disable sequence. This change is also a first step towards
> >   drm_bridge/drm_encoder unification. New encoder drivers should
> >   stop implementing drm_encoder_helper_funcs and switch to
> >   drm_bridge_funcs. Existing drivers can be converted progressively
> >   (already have a branch where I started converting some of them [1])
> > * rework the bus format negotiation to give more control to bridge
> >   drivers in the selection process (driver can select at runtime which
> >   input bus format they support for a specific output bus format based
> >   on any information available in the connector, crtc and bridge state.
> > 
> > A more detailed changelog is provided in each patch.
> > 
> > This patch series is also available here [2].
> > 
> > Thanks,
> > 
> > Boris
> > 
> > [1]https://github.com/bbrezillon/linux-0day/commits/drm-encoder-bridge
> > [2]https://github.com/bbrezillon/linux-0day/commits/drm-bridge-busfmt-v3
> > 
> > *** BLURB HERE ***
> > 
> > Boris Brezillon (21):
> >   drm/vc4: Declare the DSI encoder as a bridge element
> >   drm/exynos: Don't reset bridge->next
> >   drm/exynos: Declare the DSI encoder as a bridge element
> >   drm/bridge: Rename bridge helpers targeting a bridge chain
> >   drm/bridge: Introduce drm_bridge_chain_get_next_bridge()
> >   drm: Stop accessing encoder->bridge directly  
> 
> Patches 1 to 6 seem to be reviewed, and appear as a good
> step forward.

AFAICT, patch 1 and 3 are not reviewed, which is kind of blocking me
for patch 4-6. I can (and plan to) apply patch 2.