[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240229-crane-of-eternal-joy-f675d7@houat>
Date: Thu, 29 Feb 2024 09:21:07 +0100
From: Maxime Ripard <mripard@...nel.org>
To: "Klymenko, Anatoliy" <Anatoliy.Klymenko@....com>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
"Simek, Michal" <michal.simek@....com>, Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] drm/atomic-helper: Add select_output_bus_format
callback
Hi,
On Wed, Feb 28, 2024 at 10:00:19PM +0000, Klymenko, Anatoliy wrote:
> > > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > > b/include/drm/drm_modeset_helper_vtables.h
> > > index 881b03e4dc28..7c21ae1fe3ad 100644
> > > --- a/include/drm/drm_modeset_helper_vtables.h
> > > +++ b/include/drm/drm_modeset_helper_vtables.h
> > > @@ -489,6 +489,37 @@ struct drm_crtc_helper_funcs {
> > > bool in_vblank_irq, int *vpos, int *hpos,
> > > ktime_t *stime, ktime_t *etime,
> > > const struct drm_display_mode *mode);
> > > +
> > > + /**
> > > + * @select_output_bus_format
> > > + *
> > > + * Called by the first connected DRM bridge to negotiate input media
> > > + * bus format. CRTC is expected to pick preferable media formats from
> > > + * the list supported by the DRM bridge chain.
> >
> > There's nothing restricting it to bridges here. Please rephrase this to remove the
> > bridge mention. The user is typically going to be the encoder, and bridges are just
> > an automagic implementation of an encoder.
> >
>
> OK. I'll fix than in the next version.
>
> > And generally speaking, I'd really like to have an implementation available before
> > merging this.
> >
>
> Well, 2 instances of this callback implementations exist as drafts, as
> this is the new API. A little bit of a chicken and egg problem. I'll
> try to groom at least one of them into upstreamable shape and attach
> it to the patch set.
That's totally what I meant :)
I basically don't want to have an interface that isn't used. If you
provide an implementation in the same series, it's totally reasonable
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists