On 14:31-20201021, Tomi Valkeinen wrote: > On 16/10/2020 13:39, Nikhil Devshatwar wrote: > > When the next bridge does not specify any bus flags, use the > > bridge->timings->input_bus_flags as fallback when propagating > > bus flags from next bridge to current bridge. > > > > Signed-off-by: Nikhil Devshatwar <nikhil...@ti.com> > > --- > > drivers/gpu/drm/drm_bridge.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > > index 64f0effb52ac..8353723323ab 100644 > > --- a/drivers/gpu/drm/drm_bridge.c > > +++ b/drivers/gpu/drm/drm_bridge.c > > @@ -975,6 +975,13 @@ drm_atomic_bridge_propagate_bus_flags(struct > > drm_bridge *bridge, > > * duplicate the "dummy propagation" logic. > > */ > > bridge_state->input_bus_cfg.flags = output_flags; > > + > > + /* > > + * Use the bridge->timings->input_bus_flags as fallback if the next > > bridge > > + * does not specify the flags > > + */ > > + if (!bridge_state->input_bus_cfg.flags) > > + bridge_state->input_bus_cfg.flags = > > bridge->timings->input_bus_flags; > > According to docs, timings can be NULL. > > 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.
Got it, the flags from timings if present should be prioritized rather than treating them as fallback. Nikhil D > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
