On 23/09/14 13:01, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
On 23/09/14 11:35, Thierry Reding wrote:
Well, a display controller is never going to attach to a panel directly.
With parallel RGB, that (almost) happens. There's voltage level shifting probably in the middle, but I don't see anything else there.
The level shifting could be considered an encoder. Anyway, I didn't mean physically attach to a panel but rather in DRM. You'll always need an encoder and connector before you go to the panel.
"For now", you mean.
I'd rather see much more freedom there. If a display controller is connected to a panel directly, with only non-controllable level shifters in between (I don't even think those are strictly needed. why couldn't there be a low-end soc that works with higher voltages?), I think we should model it in the SW side by just having a device for the display controller and a device for the panel. No artificial encoders/bridges/connectors needed in between.
But I understand that for DRM legacy reasons that may never happen.
But I agree that it would be nice to unify bridges and encoders more. It should be possible to make encoder always a bridge (or perhaps even replace encoders with bridges altogether). Then once you're out of the DRM device everything would be a bridge until you get to a panel.
What exactly is a bridge and what is an encoder? Those are DRM constructs, aren't they?
Yes. I think bridges are mostly a superset of encoders.
Superset in what way? If I have a SiI9022 RGB-to-HDMI encoder embedded into my SoC (i.e. a DRM encoder), or I have a board with a SiI9022 encoder on the board (i.e. a DRM bridge), what is different?
As I see it, a video pipeline consist of a video source (display controller usually), a chain of encoders (all of which may not be strictly "encoders", they could be level shifters, muxes, ESD protection devices or such), and either a display device like a panel or a connector to outside world.
Well, the panel itself is attached to a connector. The connector is really what userspace uses to control the output and indirectly the panel.
Yep. That's also something that should be fixed. A connector SW entity is fine when connecting an external monitor, but a panel directly connected to the SoC does not have a connector, and it's the panel that should be controlled from the userspace.
But again, the legacy...
Am I right that in DRM world the encoder is the first device in the display chain after the display controller,
Yes.
and the next is a bridge?A bridge or a connector. Typically it would be a connector, but that's only if you don't have bridges in between.
That sounds totally artificial, and I hope we don't reflect that in the DT side in any way.
Yes, they are software concepts and I'm not aware of any of it being exposed in DT. A display controller is usually implemented as DRM CRTC object and outputs (DSI, eDP, HDMI) as encoder (often with a connector tied to it).
Ok. Thanks for the clarifications.
Tomi