[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240627-vengeful-glorious-stork-a70480@houat>
Date: Thu, 27 Jun 2024 11:33:10 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: 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>,
Daniel Vetter <daniel@...ll.ch>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH RFC 4/5] drm/bridge: connector: add support for HDMI
codec framework
On Fri, Jun 21, 2024 at 02:10:22PM GMT, Dmitry Baryshkov wrote:
> On Fri, 21 Jun 2024 at 12:30, Maxime Ripard <mripard@...nel.org> wrote:
> >
> > On Sat, Jun 15, 2024 at 08:53:33PM GMT, Dmitry Baryshkov wrote:
> > > Add necessary glue code to be able to use new HDMI codec framework from
> > > the DRM bridge drivers. The drm_bridge implements a limited set of the
> > > hdmi_codec_ops interface, with the functions accepting both
> > > drm_connector and drm_bridge instead of just a generic void pointer.
> > >
> > > This framework is integrated with the DRM HDMI Connector framework, but
> > > can also be used for DisplayPort connectors.
> > >
> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > > ---
> > > drivers/gpu/drm/drm_bridge_connector.c | 130 ++++++++++++++++++++++++++++++++-
> > > include/drm/drm_bridge.h | 46 ++++++++++++
> > > 2 files changed, 174 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c
> > > index 0869b663f17e..71d6fdc2391f 100644
> > > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > > @@ -20,6 +20,8 @@
> > > #include <drm/drm_probe_helper.h>
> > > #include <drm/display/drm_hdmi_state_helper.h>
> > >
> > > +#include <sound/hdmi-codec.h>
> > > +
> > > /**
> > > * DOC: overview
> > > *
> > > @@ -95,6 +97,14 @@ struct drm_bridge_connector {
> > > * HDMI connector infrastructure, if any (see &DRM_BRIDGE_OP_HDMI).
> > > */
> > > struct drm_bridge *bridge_hdmi;
> > > + /**
> > > + * @bridge_hdmi_codec:
> > > + *
> > > + * The bridge in the chain that implements necessary support for the
> > > + * HDMI Audio Codec infrastructure, if any (see
> > > + * &DRM_BRIDGE_OP_HDMI_CODEC).
> > > + */
> > > + struct drm_bridge *bridge_hdmi_codec;
> >
> > Can we have a setup where one bridge would support the video stream and
> > another one the audio?
> >
> > I think for now I'd rather make them both provided by the same bridge,
> > and we can always change that later on if we need to.
>
> The same point here (and for your second comment): DisplayPort audio
> support.
Well, yeah, but then we can do the same thing for DisplayPort and share
some code when needed.
And like I said, we can change that later if we need to, but there's no
point in trying to make something super flexible if we're not quite sure
what the requirements are.
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists