Devicetree
 help / color / mirror / Atom feed
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Dmitry Baryshkov <lumag@kernel.org>
Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	 kernel@collabora.com
Subject: Re: [PATCH RFC v3 09/10] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells
Date: Wed, 15 Jul 2026 21:16:27 +0200	[thread overview]
Message-ID: <alfYxIkbJMA36qdt@venus> (raw)
In-Reply-To: <20260612-synopsys-dw-dp-improvements-v3-9-dc61e6352508@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 3922 bytes --]

Hi DT binding maintainers (& Dmitry for his DP background),

Can you have a look at this please? It has been a month, since I
send this and multiple months since I send RFCv1. Would be good
to have your preference here, so that I can implement it accordingly
in the next version.

On Fri, Jun 12, 2026 at 08:00:55PM +0200, Sebastian Reichel wrote:
> The RK3588 and RK3576 DesignWare DisplayPort controllers both have two
> possible DAI interfaces: I2S and S/PDIF. Thus it is needed to have an
> argument to select the right interface.
> 
> In case of RK3576 this is not enough though. The RK3576 has the same IP
> as RK3588, but configured with Multi Stream Transport (MST) enabled for
> up to 3 displays and thus has a total of 6 DAI interfaces (I2S and
> S/PDIF for each possible stream. Meanwhile the RK3588 does not support
> MST and thus has only 2 DAI interfaces.
> 
> The binding update right now only supports the simple single stream
> transport (SST) setup. To avoid further DT ABI breakage (or complicated
> bindings supporting different number of arguments), it's probably a good
> idea to take MST into account now even though the upstream Linux driver
> does not yet support it.
> 
> I see two options:
> 
> 1. Adding yet another cell, so that we have the following:
>    <&dp_ctrl [display_stream] [i2s_or_spdif]>; potentially append
>    extra input ports for MST video data to existing ports node
>    (e.g. port@2). I would only handle the sound DAI part in my
>    patch and basically use '0' for the display stream and just
>    leave the option of using '1' or '2' once MST support is added.

My guess is, that this is preferred.

> 2. The vendor kernel creates a sub-node for each supported display
>    stream and puts the ports mapping as well as the DAI reference
>    into that. This bundles all information for one display stream
>    together, which creates a clean look but the subnode does not
>    really describe any real thing in the hardware.

FWIW that looks like this:

dp@<address> {
    props-from-this-binding;

    /* SST or MST stream 0 */
    dp0 {
        #sound-dai-cells = <1>;
        ports { ... };
    };

    /* MST stream 1 */
    dp1 {
        #sound-dai-cells = <1>;
        ports { ... };
    };

    /* MST stream 2 */
    dp2 {
        #sound-dai-cells = <1>;
        ports { ... };
    };
};

While the grouping looks nice to me from the audio/video controller
to DP controller point of view, it's less sensible for the
connection from the DP controller to the DP/USB-C connector as all
streams are bundled at that point.

Thanks and greetings,

-- Sebastian

> As upstream MST support seems to be quite limited, I wish for some
> feedback about the preferred way to handle this.
> 
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
>  .../devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml         | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> index 2b0d9e23e943..1303d0e2145a 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> @@ -83,7 +83,8 @@ properties:
>      maxItems: 1
>  
>    "#sound-dai-cells":
> -    const: 0
> +    const: 1
> +    description: 0 for I2S, 1 for SPDIF
>  
>  required:
>    - compatible
> @@ -144,7 +145,7 @@ examples:
>          resets = <&cru SRST_DP0>;
>          phys = <&usbdp_phy0 PHY_TYPE_DP>;
>          power-domains = <&power RK3588_PD_VO0>;
> -        #sound-dai-cells = <0>;
> +        #sound-dai-cells = <1>;
>  
>          ports {
>            #address-cells = <1>;
> 
> -- 
> 2.53.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2026-07-15 19:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12 18:00 [PATCH v3 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms Sebastian Reichel
2026-06-12 18:00 ` [PATCH v3 01/10] drm/bridge: synopsys: dw-dp: Simplify driver data setting Sebastian Reichel
2026-06-12 18:00 ` [PATCH v3 02/10] drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED Sebastian Reichel
2026-06-12 18:00 ` [PATCH v3 03/10] drm/bridge: synopsys: dw-dp: Add follow-up bridge support Sebastian Reichel
2026-06-23 19:49   ` sashiko-bot
2026-06-12 18:00 ` [PATCH v3 04/10] drm/bridge: Add out-of-band HPD notify handler Sebastian Reichel
2026-06-12 18:00 ` [PATCH v3 05/10] drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD Sebastian Reichel
2026-06-23 20:11   ` sashiko-bot
2026-06-12 18:00 ` [PATCH v3 06/10] drm/rockchip: dw_dp: Implement out-of-band HPD handling Sebastian Reichel
2026-06-23 20:20   ` sashiko-bot
2026-06-12 18:00 ` [PATCH v3 07/10] drm/bridge: synopsys: dw-dp: Add Runtime PM support Sebastian Reichel
2026-06-23 20:31   ` sashiko-bot
     [not found]   ` <CANbgqAQLROuf9wvZZWRufZg6iqubKnC4fW5Bh+DkQ7RP1x5KKQ@mail.gmail.com>
2026-07-15 18:31     ` Sebastian Reichel
2026-06-12 18:00 ` [PATCH v3 08/10] drm/rockchip: dw_dp: Add runtime " Sebastian Reichel
2026-06-23 20:40   ` sashiko-bot
     [not found]   ` <CANbgqATR-V0rRGfzj0hdJ2hsJex-iWzHMwD1L4vavTi2Jd79Kw@mail.gmail.com>
2026-07-15 19:00     ` Sebastian Reichel
2026-07-15 19:30       ` Heiko Stuebner
2026-07-16  3:38         ` Andy Yan
2026-06-12 18:00 ` [PATCH RFC v3 09/10] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells Sebastian Reichel
2026-06-23 20:51   ` sashiko-bot
2026-07-15 19:16   ` Sebastian Reichel [this message]
2026-06-12 18:00 ` [PATCH v3 10/10] drm/bridge: synopsys: dw-dp: Add audio support Sebastian Reichel
2026-06-23 21:00   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alfYxIkbJMA36qdt@venus \
    --to=sebastian.reichel@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=lumag@kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox