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
Attachment:
signature.asc
Description: OpenPGP digital signature
