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

From: Thierry Reding <thierry.reding@gmail.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "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>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	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 16:41:28 +0200	[thread overview]
Message-ID: <20140923144127.GE5982@ulmo> (raw)
In-Reply-To: <54214CCE.7050102@samsung.com>

[-- Attachment #1.1: Type: text/plain, Size: 2514 bytes --]

On Tue, Sep 23, 2014 at 12:34:54PM +0200, Andrzej Hajda wrote:
> On 09/23/2014 12:10 PM, Thierry Reding wrote:
> > On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
> >> On 09/23/2014 10:35 AM, Thierry Reding wrote:
> > [...]
> >>> 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.
> >> I agree that some sort of unification of bridges, (slave) encoders is a good
> >> thing, this way we stay only with bridges and panels as receivers.
> >> But we will still have to deal with the code like:
> >>     if (on the other end of the link is panel)
> >>         do panel framework specific things
> >>     else
> >>         do bridge framework specific things
> >>
> >> The code in both branches usually does similar things but due to framework
> >> differences it is difficult to merge.
> > That's because they are inherently different entities. You can perform
> > operations on a panel that don't make sense for a bridge and vice-versa.
> >
> >> Ideally it would be best to get rid of such constructs. For example by
> >> trying to
> >> make frameworks per interface type exposed by device (eg. video_sink) and
> >> not by device type (drm_bridge, drm_panel).
> > But then you loose all information about the real type of device.
> Driver knows type of its device anyway. Why should it know device
> type of devices it is connected to? It is enough it knows how to talk to
> other device.
> Like in real world, why desktop PC should know it is connected to DVI
> monitor or to
> DVI/HDMI converter which is connected to TV?

TVs are much more standardized. There are things like DDC/CI which can
be used to control the device. Or there's additional circuitry or
control paths to change things like brightness. The same isn't true of
panels.

> >  Or you
> > have to create a common base class. And then you're still back to
> > dealing with the two specific cases in many places, so the gain seems
> > rather minimal.
> 
> For example RGB panel and RGB/??? bridge have the same hardware input
> interface.
> Why shall they have different representation in kernel?

Because panels have different requirements than bridges. Panels for
example require the backlight to be adjustable, bridges don't.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel