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