On 30/11/2020 11:36, Laurent Pinchart wrote:
Hi Nikhil,
Thank you for the patch.
On Thu, Nov 19, 2020 at 09:31:29PM +0530, Nikhil Devshatwar wrote:
bus_flags can be specified by a bridge in the timings. If the bridge provides it, Override the bus_flags when propagating from next bridge.
Signed-off-by: Nikhil Devshatwar nikhil.nd@ti.com Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com
Notes: changes from v2: * update comment changes from v1: * Check for timings * Prioritize timings flags over next bridge's flags
drivers/gpu/drm/drm_bridge.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 64f0effb52ac..13b67fc0dad3 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -975,6 +975,14 @@ drm_atomic_bridge_propagate_bus_flags(struct drm_bridge *bridge, * duplicate the "dummy propagation" logic. */ bridge_state->input_bus_cfg.flags = output_flags;
- /*
* If legacy bus flags are provided in bridge->timings, use those as* input flags instead of propagating the output flags.*/- if (bridge->timings && bridge->timings->input_bus_flags)
bridge_state->input_bus_cfg.flags =bridge->timings->input_bus_flags;Hasn't Boris commented in his review of v1 that bus flags should be set in atomic_check, even when they're static ? We're moving towards removing timings->input_bus_flags, so this patch goes in the wrong direction :-S
We have atomic_check only if the bridge has implemented atomic funcs. And even if there's atomic_check, not all bridges set the bus_flags there. So we need to either 1) fix the issue for now as in this patch, or 2) convert all bridges to use atomic funcs and fix all the bridges to set the bus_flags.
Tomi