linux-kernel - Re: [PATCH v5 2/2] drm/msm/dp: reuse generic HDMI codec implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ecw5wdvkf2iqwxvigze374q3lb3esqbokv43mkblbnpfmudutu@e75i4lqhuux7>
Date: Tue, 11 Mar 2025 17:58:19 +0200
From: Dmitry Baryshkov <lumag@...nel.org>
To: Maxime Ripard <mripard@...nel.org>
Cc: Dmitry Baryshkov <dbaryshkov@...il.com>, 
	Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Rob Clark <robdclark@...il.com>, 
	Abhinav Kumar <quic_abhinavk@...cinc.com>, Sean Paul <sean@...rly.run>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, Hermes Wu <Hermes.wu@....com.tw>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	freedreno@...ts.freedesktop.org
Subject: Re: [PATCH v5 2/2] drm/msm/dp: reuse generic HDMI codec
 implementation

On Tue, Mar 11, 2025 at 09:41:13AM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Mar 10, 2025 at 08:53:24PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 10 Mar 2025 at 17:08, Maxime Ripard <mripard@...nel.org> wrote:
> > >
> > > On Fri, Mar 07, 2025 at 07:55:53AM +0200, Dmitry Baryshkov wrote:
> > > > From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > > >
> > > > The MSM DisplayPort driver implements several HDMI codec functions
> > > > in the driver, e.g. it manually manages HDMI codec device registration,
> > > > returning ELD and plugged_cb support. In order to reduce code
> > > > duplication reuse drm_hdmi_audio_* helpers and drm_bridge_connector
> > > > integration.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > > > ---
> > > >  drivers/gpu/drm/msm/Kconfig         |   1 +
> > > >  drivers/gpu/drm/msm/dp/dp_audio.c   | 131 ++++--------------------------------
> > > >  drivers/gpu/drm/msm/dp/dp_audio.h   |  27 ++------
> > > >  drivers/gpu/drm/msm/dp/dp_display.c |  28 ++------
> > > >  drivers/gpu/drm/msm/dp/dp_display.h |   6 --
> > > >  drivers/gpu/drm/msm/dp/dp_drm.c     |   8 +++
> > > >  6 files changed, 31 insertions(+), 170 deletions(-)
> > > >

[...]

> > > >
> > > >  static int msm_edp_bridge_atomic_check(struct drm_bridge *drm_bridge,
> > > > @@ -320,9 +324,13 @@ int msm_dp_bridge_init(struct msm_dp *msm_dp_display, struct drm_device *dev,
> > > >        */
> > > >       if (!msm_dp_display->is_edp) {
> > > >               bridge->ops =
> > > > +                     DRM_BRIDGE_OP_HDMI_AUDIO |
> > > >                       DRM_BRIDGE_OP_DETECT |
> > > >                       DRM_BRIDGE_OP_HPD |
> > > >                       DRM_BRIDGE_OP_MODES;
> > > > +             bridge->hdmi_audio_dev = &msm_dp_display->pdev->dev;
> > > > +             bridge->hdmi_audio_max_i2s_playback_channels = 8;
> > > > +             bridge->hdmi_audio_dai_port = -1;
> > > >       }
> > >
> > > I think I'd prefer the toggle to be OP_DP_AUDIO, even if the
> > > implementation is exactly the same. That way, we'll be able to condition
> > > it to the DP support when that arrives, and we have the latitude to
> > > rework it to accomodate some DP subtleties without affecting the drivers
> > > later on.
> > 
> > I don't think that there is a point in having OP_DP_AUDIO. There is
> > not so much difference in the driver. Also currently OP_HDMI_AUDIO
> > follows existing approach (which was pointed out by Laurent) - that
> > OP_foo should guard a particular set of callbacks. From this
> > perspective, OP_HDMI_AUDIO is fine - it guards usage of
> > hdmi_audio_foo(). OP_DP_AUDIO would duplicate that.
> 
> HDMI and DP are two competing standards, with different governing
> bodies. I don't think either have claimed that they will strictly adhere
> to what the other is doing, and I don't have the will to cross-check
> every given audio feature in both HDMI and DP right now.

Hmm. Currently (or before the first hdmi_audio patchset) everybody has
been plumbing hdmi-codec directly from the driver (even for DP audio).

> However, I think we should really have the flexibility to deal with that
> situation if it happens, and without having to do any major refactoring.
> That means providing an API that is consistent to the drivers, and
> provides what the driver needs. Here, it needs DP audio support, not
> HDMI's.

Would OP_HDMI_CODEC be a better name for the OP? (we can rename the
existing callbacks to be hdmi_codec instead of hdmi_audio too).

> How we plumb it is an implementation detail, and I do agree we can use
> the same functions under the hood right now. But the driver is a DP
> driver, it wants DP infrastructure and DP audio support.

Would OP_DP_AUDIO require a different set of callbacks on the bridge
level? I don't want to end up with too much of duplication. Maybe we
should the cdns bridges which implement both HDMI and DP functionality
IIRC.


-- 
With best wishes
Dmitry