On Fri, 30 Oct 2020 09:30:01 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
