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

[Tomi Valkeinen]

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 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?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki