Message ID | 20191023154512.9762-1-boris.brezillon@collabora.com (mailing list archive) |
---|---|
Headers | show |
Series | drm: Add support for bus-format negotiation | expand |
hi Boris, On 23/10/2019 17:44, 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 Seems you forgot my reviewed-bys on patches 5, 8, 11 & 13 > > 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]. Will test ASAP. > > 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 *** Blurp Neil > > 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 > drm/bridge: Make the bridge chain a double-linked list > drm/bridge: Add the drm_for_each_bridge_in_chain() helper > drm/bridge: Add a drm_bridge_state object > drm/bridge: Clarify the atomic enable/disable hooks semantics > drm/bridge: Patch atomic hooks to take a drm_bridge_state > drm/bridge: Add an ->atomic_check() hook > drm/bridge: Add the drm_bridge_chain_get_prev_bridge() helper > drm/bridge: Add the necessary bits to support bus format negotiation > drm/imx: pd: Use bus format/flags provided by the bridge when > available > drm/bridge: lvds-encoder: Implement basic bus format negotiation > dt-bindings: display: bridge: lvds-transmitter: Add new props > drm/bridge: panel: Propage bus format/flags > drm/panel: simple: Add support for Toshiba LTA089AC29000 panel > dt-bindings: display: panel: Add the LTA089AC29000 variant > ARM: dts: imx: imx51-zii-rdu1: Fix the display pipeline definition > > .../display/bridge/lvds-transmitter.txt | 13 + > .../display/panel/toshiba,lt089ac29000.txt | 5 +- > arch/arm/boot/dts/imx51-zii-rdu1.dts | 24 +- > .../drm/bridge/analogix/analogix_dp_core.c | 12 +- > drivers/gpu/drm/bridge/lvds-encoder.c | 72 ++ > drivers/gpu/drm/bridge/panel.c | 1 + > drivers/gpu/drm/drm_atomic.c | 39 + > drivers/gpu/drm/drm_atomic_helper.c | 54 +- > drivers/gpu/drm/drm_bridge.c | 800 +++++++++++++++--- > drivers/gpu/drm/drm_encoder.c | 15 +- > drivers/gpu/drm/drm_probe_helper.c | 4 +- > drivers/gpu/drm/exynos/exynos_dp.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 90 +- > drivers/gpu/drm/imx/parallel-display.c | 174 +++- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 +- > drivers/gpu/drm/msm/edp/edp_bridge.c | 10 +- > drivers/gpu/drm/omapdrm/omap_drv.c | 4 +- > drivers/gpu/drm/omapdrm/omap_encoder.c | 3 +- > drivers/gpu/drm/panel/panel-simple.c | 36 + > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 +- > drivers/gpu/drm/vc4/vc4_dsi.c | 90 +- > include/drm/drm_atomic.h | 3 + > include/drm/drm_bridge.h | 396 ++++++++- > include/drm/drm_encoder.h | 9 +- > 24 files changed, 1588 insertions(+), 286 deletions(-) >
On Thu, 24 Oct 2019 13:27:16 +0200 Neil Armstrong <narmstrong@baylibre.com> wrote: > hi Boris, > > On 23/10/2019 17:44, 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 > > Seems you forgot my reviewed-bys on patches 5, 8, 11 & 13 Oops, indeed. Can you add them back?
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. Perhaps we can consider merging these first? That way, we can reduce the patches needed to rebase and submit on each iteration. Regards, Ezequiel
On Sun, 24 Nov 2019 09:46:41 +0900 Ezequiel Garcia <ezequiel@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.
On Sun, 2019-11-24 at 08:32 +0100, Boris Brezillon wrote: > On Sun, 24 Nov 2019 09:46:41 +0900 > Ezequiel Garcia <ezequiel@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