Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]