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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
