Re: [PATCH 3/5] drm: bridge: Propagate the bus flags from bridge->timings

From: Boris Brezillon <boris.brezillon@collabora.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Swapnil Jakhade <sjakhade@cadence.com>,
	Sekhar Nori <nsekhar@ti.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	dri-devel@lists.freedesktop.org,
	Nikhil Devshatwar <nikhil.nd@ti.com>
Subject: Re: [PATCH 3/5] drm: bridge: Propagate the bus flags from bridge->timings
Date: Fri, 30 Oct 2020 09:08:15 +0100	[thread overview]
Message-ID: <20201030090815.7133637b@collabora.com> (raw)
In-Reply-To: <dfb643a6-cb73-c915-21ff-387faa177c94@ti.com>

On Fri, 30 Oct 2020 09:30:01 +0200
Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:

> On 30/10/2020 00:48, Laurent Pinchart wrote:
> 
> >>> And, hmm... It's too easy to get confused with these, but... If the bridge defines timings, and
> >>> timings->input_bus_flags != 0, should we always pick that, even if we got something via
> >>> output_flags? Logic being, if this bridge defines timings->input_bus_flags, it probably wants that
> >>> to be used regardless whether we got something from the next bridge.  
> > 
> > timings->input_bus_flags is an API that predates format and flags
> > propagation along the pipeline. I would assume that drivers that
> > implement propagation should do so in a way that prioritize that API,
> > and either not report flags in the timings (in which case giving
> > priority to one or another wouldn't make a difference as both would
> > never be provided together), or would report flags in the timings as a
> > best effort fallback for display controller drivers that would look at
> > them exclusively without supporting the new API. I would thus think that
> > the flags obtained through format negotiation should be prioritized.  
> 
> What do you mean "drivers that implement propagation"? Doesn't that come from the framework, not
> from the drivers?
> 
> Say, we have two bridges, A -> B. A has timings->input_bus_flags.
> 
> When propagating the flags, we get something as B's input flags. Should A use B's input flags as A's
> input flags, or should A use its timings->input_bus_flags? I was suggesting the latter. Nikhil's
> patch does the latter, but only if B's input flags was 0.

A should definitely use timings->input_bus_flags in that case.

> 
> A can override its input flags manually in atomic_check, but if the timings->input_bus_flags exists,
> isn't it a sane choice to just pick that by default?

The "propagate output flags" and soon to be added "use
timing->input_flags if present" logic should only be used as a fallback
for bridges that do not support dynamic bus format/flags negotiation
IMHO. Ideally we'd want to convert all bridges to do this dynamic bus
format/flags negotiation and get rid of timings->input_bus_flags once
this is done, but that's likely to take time. So, if your driver
implements the ->atomic_check() hook and needs specific input flags,
I'd recommend setting the input flags there instead of specifying it
through timings->input_bus_flags.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel