devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Sean Paul <seanpaul@google.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	sunil joshi <joshi@samsung.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Ajay kumar <ajaynumb@gmail.com>,
	Prashanth G <prashanth.g@samsung.com>,
	Ajay Kumar <ajaykumar.rs@samsung.com>
Subject: Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Date: Tue, 23 Sep 2014 18:33:56 +0300	[thread overview]
Message-ID: <542192E4.70007@ti.com> (raw)
In-Reply-To: <20140923143854.GD5982@ulmo>

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

On 23/09/14 17:38, Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 03:09:44PM +0300, Tomi Valkeinen wrote:
>> On 23/09/14 13:01, Thierry Reding wrote:
>>> On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
> [...]
>>>> 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?
> 
> Superset in what they represent from a software point of view. As in:
> an encoder /is a/ bridge. Though they aren't currently implemented that
> way.

So they are equal, not superset? Or what does an encoder do that a
bridge doesn't?

>>>> 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.
> 
> I disagree. A panel is usually also attached using some sort of
> connector. Maybe not an HDMI, VGA or DP connector, but still some sort
> of connector where often it can even be removed.

Yes, but a normal panel connector is really just an extension of wires.
There is no difference if you wire the panel directly to the video
source, or if there's a connector.

I think usually connectors to the external world are not quite as
simple, as there may be some protection components or such, but even if
there's nothing extra, they are still a clear component visible to
outside world. For HDMI you (sometimes) even need properties for the
connector, like source for +5V, i2c bus, hotplug pin.

But even if there are no extra properties like that, I still think it's
good to have a connector entity for a connector to outside world.
Whereas I don't see any need for such when the connector is internal.
That said, I don't see any reason to prevent that either.

> Panels are theoretically hot-pluggable, too, much in the same way that
> monitors are.

So are encoders, in the same way. I have a main board, with a video
connector. That goes to an encoder on display board, and that again has
a connector, to which the panel is connected.

I also have a panel that can be conneted directly to the main board's
video output.

>> But again, the legacy...
> 
> You've got to make the abstraction somewhere, and I'm quite surprised
> actually how well the DRM abstractions are working out. I mean we can
> support anything from HDMI to DP to eDP, DSI and LVDS with just the
> connector abstraction and it all just works. That makes it a pretty
> good abstraction in my book.

Yes, I agree it's good in the sense that it works. And much better than
fbdev, which has nothing. But it's not good in the sense that it's not
what I'd design if I could start from scratch.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-09-23 15:33 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 14:39 [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties Ajay Kumar
2014-08-27 14:39 ` [PATCH V7 10/12] Documentation: devicetree: Add vendor prefix for parade Ajay Kumar
2014-08-27 14:39 ` [PATCH V7 09/12] Documentation: drm: bridge: move to video/bridge Ajay Kumar
2014-09-17 11:52 ` [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties Tomi Valkeinen
2014-09-17 14:29   ` Ajay kumar
2014-09-17 16:22     ` Tomi Valkeinen
2014-09-18  5:50       ` Ajay kumar
2014-09-19 12:54         ` Tomi Valkeinen
2014-09-19 13:59           ` Ajay kumar
2014-09-19 14:28             ` Tomi Valkeinen
2014-09-20 11:22               ` Ajay kumar
2014-09-20 15:27                 ` Javier Martinez Canillas
2014-09-22  6:00                   ` Ajay kumar
2014-09-22 15:05                   ` Tomi Valkeinen
2014-10-07 10:30                 ` Tomi Valkeinen
2014-10-07 10:36                   ` Ajay kumar
2014-10-07 14:49                     ` Laurent Pinchart
2014-10-08  7:09                       ` Thierry Reding
2014-10-10 13:03                         ` Ajay kumar
2014-10-16  8:23                           ` Ajay kumar
2014-10-16  9:04                           ` Laurent Pinchart
2014-10-28  9:12                             ` Javier Martinez Canillas
2014-10-28 11:12                               ` Ajay kumar
2014-09-22  8:26               ` Thierry Reding
2014-09-22 14:42                 ` Tomi Valkeinen
2014-09-23  5:53                   ` Thierry Reding
2014-09-23  8:41                     ` Tomi Valkeinen
2014-09-23  9:28                       ` Thierry Reding
2014-09-23 11:15                         ` Tomi Valkeinen
2014-09-23 14:29                           ` Thierry Reding
2014-09-23 15:25                             ` Tomi Valkeinen
2014-09-22  8:10         ` Thierry Reding
2014-09-22  8:31           ` Ajay kumar
2014-09-22 10:41             ` Thierry Reding
2014-09-22 11:23               ` Ajay kumar
2014-09-22 11:35                 ` Thierry Reding
2014-09-22 12:12                   ` Ajay kumar
2014-09-23  0:00                   ` Laurent Pinchart
2014-09-23  5:55                     ` Thierry Reding
2014-09-23  6:11                       ` Ajay kumar
2014-09-23  6:28                         ` Thierry Reding
2014-09-23 11:47                       ` DT property to selectively disable device features (was [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties) Laurent Pinchart
2014-09-22  8:06       ` [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties Thierry Reding
2014-09-22 14:23         ` Tomi Valkeinen
2014-09-23  6:04           ` Thierry Reding
2014-09-23  7:24             ` Andrzej Hajda
2014-09-23  8:35               ` Thierry Reding
2014-09-23  9:40                 ` Tomi Valkeinen
2014-09-23 10:01                   ` Thierry Reding
2014-09-23 12:09                     ` Tomi Valkeinen
2014-09-23 14:38                       ` Thierry Reding
2014-09-23 15:33                         ` Tomi Valkeinen [this message]
2014-09-23  9:43                 ` Andrzej Hajda
2014-09-23 10:10                   ` Thierry Reding
2014-09-23 10:34                     ` Andrzej Hajda
2014-09-23 14:41                       ` Thierry Reding
2014-09-24  7:11                         ` Andrzej Hajda
2014-09-24  8:27                         ` Tomi Valkeinen
2014-09-23 11:33                     ` Laurent Pinchart
2014-09-23  8:54             ` Tomi Valkeinen
2014-09-23  9:39               ` Thierry Reding
2014-09-23 11:31                 ` Tomi Valkeinen
2014-09-23 14:45                   ` Thierry Reding
2014-09-24  8:42                     ` Tomi Valkeinen
2014-10-06 14:40                       ` Laurent Pinchart
2014-10-07  7:06                         ` Tomi Valkeinen
2014-10-07  7:23                           ` Laurent Pinchart
2014-10-07  8:25                             ` Tomi Valkeinen
2014-10-07 16:14                               ` Laurent Pinchart
2014-09-22  7:54   ` Thierry Reding
2014-09-22 14:04     ` Tomi Valkeinen
2014-09-23  6:21       ` Thierry Reding
2014-09-23  9:30         ` Tomi Valkeinen
2014-09-23  9:53           ` Thierry Reding
2014-09-23 11:12             ` Laurent Pinchart
2014-09-23 14:50               ` Thierry Reding
2014-09-23 12:00             ` Tomi Valkeinen
2014-09-23 14:58               ` Thierry Reding
2014-09-24  9:08                 ` Tomi Valkeinen
2014-09-25  6:23                   ` Thierry Reding
2014-10-06 11:34                     ` Tomi Valkeinen
2014-10-06 13:55                       ` Laurent Pinchart
2014-09-23 10:02           ` Andrzej Hajda
2014-09-23 10:02           ` Andrzej Hajda
2014-09-23 11:10             ` Laurent Pinchart
2014-09-23 11:18               ` Andrzej Hajda
2014-09-23 11:23                 ` Laurent Pinchart
2014-09-23 11:47                   ` Andrzej Hajda
2014-09-23 11:52                     ` Laurent Pinchart
2014-09-23 12:40                       ` Andrzej Hajda
2014-09-23 12:40                       ` Andrzej Hajda
2014-09-23 14:49                       ` Thierry Reding
2014-10-06 14:38                         ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542192E4.70007@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=a.hajda@samsung.com \
    --cc=ajaykumar.rs@samsung.com \
    --cc=ajaynumb@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=joshi@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=prashanth.g@samsung.com \
    --cc=seanpaul@google.com \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).