On Sun, 2019-11-24 at 08:32 +0100, Boris Brezillon wrote: > On Sun, 24 Nov 2019 09:46:41 +0900 > Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
