mbox series

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

Message ID 20191023154512.9762-1-boris.brezillon@collabora.com (mailing list archive)
Headers show
Series drm: Add support for bus-format negotiation | expand

Message

Boris Brezillon Oct. 23, 2019, 3:44 p.m. UTC
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
  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(-)

Comments

Neil Armstrong Oct. 24, 2019, 11:27 a.m. UTC | #1
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(-)
>
Boris Brezillon Oct. 24, 2019, 1:22 p.m. UTC | #2
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?
Ezequiel Garcia Nov. 24, 2019, 12:46 a.m. UTC | #3
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
Boris Brezillon Nov. 24, 2019, 7:32 a.m. UTC | #4
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.
Ezequiel Garcia Nov. 24, 2019, 9:34 a.m. UTC | #5
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