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

[Ezequiel Garcia]

On Sun, 2019-11-24 at 08:32 +0100, Boris Brezillon wrote:
> 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.

Ah, you are right. Let's add Eric for vc4 and Inki for exynos.

For reference, here is the series: https://patchwork.kernel.org/project/dri-devel/list/?series=192359

Thanks,
Ezequiel