On Fri, 30 Oct 2020 10:40:46 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > Hi Boris, > > On 30/10/2020 10:08, Boris Brezillon wrote: > > 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. > > What is bus flags negotiation? Don't we have negotiation only for bus formats? Bus flags are just > set, and the previous bridge in the chain has to use those flags. Well, there's currently no such negotiation, but I don't see why there wouldn't be one at some point if bridges can configure it dynamically (in you A -> B example, A output flags must match B input flags, and if both A and B can configure those dynamically, they need to negotiate that part too). > > Or do you just refer to setting the bus flags dynamically in atomic_check, versus static in > input_bus_flags? Yes, that's what I suggest, even if those flags are static right now. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
