Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Yuti Amonkar <yamonkar@cadence.com>, Sekhar Nori <nsekhar@ti.com>,
	dri-devel@lists.freedesktop.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Swapnil Jakhade <sjakhade@cadence.com>,
	Nikhil Devshatwar <nikhil.nd@ti.com>
Subject: Re: [PATCH v4 5/7] drm/tidss: Set bus_format correctly from bridge/connector
Date: Fri, 4 Dec 2020 13:47:05 +0200	[thread overview]
Message-ID: <1ab0f05c-866b-c028-12c0-50766f2132e6@ti.com> (raw)
In-Reply-To: <20201204121235.4bbbe2eb@collabora.com>

On 04/12/2020 13:12, Boris Brezillon wrote:

>>> 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?
> 
> The idea is to hide the encoder abstraction from drivers as much as we
> can. We have to keep the encoder concept because that's what we expose
> to userspace, but drivers shouldn't have to worry about the distinction
> between the first bridge in the chain (what we currently call encoders)
> and other bridges. The bridge interface provides pretty much the same
> functionality, so all you need to do is turn your encoder driver into a
> bridge driver (see what we did for
> drivers/gpu/drm/imx/parallel-display.c), the only particularity here is
> that the bridge knows it's the first in the chain, and has access to
> the CRTC it's directly connected to.

With a quick look, the imx parallel-display.c seems to be really part of the crtc. Shouldn't we then
take one more step forward, and just combine the crtc, encoder and bridge (somehow)? That's kind of
what parallel-display.c is doing, isn't it? It's directly poking the crtc state, but the code just
happens to be in a separate file from the crtc.

Thinking about the TI HW, we have a bunch of internal IPs which are clearly bridges: HDMI, DSI,
which get the pixel data from the display controller, and they have their own registers, so clearly
independent bridges.

Then we have MIPI DPI, which doesn't really have its own registers, as it's just plain parallel RGB,
the same as what is sent to e.g. HDMI and DSI bridges. However, there might be some muxes or
regulators to set up to get the external signals working. So a bridge would be ok here too to handle
that external side.

But in all the above cases, we have the display controller (crtc), which in all the cases needs to
do e.g. pixel/bus format configuration. So why add direct crtc poking into the first bridges (HDMI,
DSI, DPI), when we could just model the crtc as a bridge, and thus the first bridges wouldn't need
to touch the crtc.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel