Re: [PATCH v3 4/6] drm/tidss: Set bus_format correctly from bridge/connector

[Nikhil Devshatwar <nikhil.nd@ti.com>]

On 11:46-20201130, Laurent Pinchart wrote:
> Hi Nikhil,
> 
> On Mon, Nov 30, 2020 at 12:05:03PM +0530, Nikhil Devshatwar wrote:
> > On 14:51-20201125, Tomi Valkeinen wrote:
> > > On 19/11/2020 18:01, Nikhil Devshatwar wrote:
> > > > Remove the old code to iterate over the bridge chain, as this is
> > > > already done by the framework.
> > > > The bridge state should have the negotiated bus format and flags.
> > > > Use these from the bridge's state.
> > > > If the bridge does not support format negotiation, error out
> > > > and fail.
> > > > 
> > > > Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
> > > > Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > > ---
> > > > 
> > > > Notes:
> > > >     changes from v2:
> > > >     * Remove the old code and use the flags from the bridge state
> > > > 
> > > >  drivers/gpu/drm/tidss/tidss_encoder.c | 36 +++++++++++----------------
> > > >  1 file changed, 14 insertions(+), 22 deletions(-)
> > > 
> > > If a first bridge (after the crtc) supports two bus formats as input, how does tidss choose between
> > > those? This patch just picks bstate->input_bus_cfg.format, and it's not clear to me which one that
> > > is (the first one?). Also, we don't check if tidss actually supports the bus format.
> > 
> > The selection is done by the framework in
> > select_bus_fmt_recursive at drivers/gpu/drm/drm_bridge.c:810
> > 
> > My understanding is that currently, the format negotiation logic does
> > not negotiate all the way till encoder, it stops only at the
> > first_bridge.
> 
> Should we then implement a bridge in the tidss driver to model the
> internal encoder, in order to support format negotiation all the way to
> the tidss ?

I am not sure. Scope of this series is to enable tidss with new
connector model. As of now, there aren't any bridges that report
unsupported format, so nothing is broken.

When the bridge drivers start reporting unsupported formats, we can
evaluate if it makes sense to implement the internal encoder as a bridge.

Nikhi Devshatwar

> 
> -- 
> Regards,
> 
> Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel