Hi Boris,
On 04/12/2020 12:50, Boris Brezillon wrote:
> On Tue, 1 Dec 2020 17:48:28 +0530
> Nikhil Devshatwar <nikhil.nd@xxxxxx> 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.
>
> That'd be even better if you implement the bridge interface instead of
> the encoder one so we can get rid of the encoder_{helper}_funcs and use
> drm_simple_encoder_init().
I'm a bit confused here. What should be the design here...
These formats need to be handled by the crtc (well, the display controller, which is modeled as the
crtc). Should we have a tidss_crtc.c file, which implements a crtc, a simple encoder and a bridge?
And just consider those three DRM components as different API parts of the display controller?
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
