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.nd@xxxxxx> > > --- > > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
