All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Archit Taneja <architt@codeaurora.org>
Cc: Eric Anholt <eric@anholt.net>,
	dri-devel@lists.freedesktop.org,
	Yannick Fertre <yannick.fertre@st.com>,
	Thierry Reding <treding@nvidia.com>,
	linux-kernel@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
Date: Wed, 3 May 2017 11:32:17 +0200	[thread overview]
Message-ID: <20170503093217.shqduwoq7j6ag4jc@phenom.ffwll.local> (raw)
In-Reply-To: <dfa5416a-ea7f-f3f3-4d63-d80b9fab443d@codeaurora.org>

On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> +panel/bridge reviewers.
> 
> This does make things much cleaner, but it seems a bit strange to create
> a drm_bridge when there isn't really a HW bridge in the display chain (i.e,
> when the DSI encoder is directly connected to a DSI panel).
> 
> There are kms drivers that use drm_panel, but don't have simple stub connectors
> that wrap around a drm_panel. They have more complicated connector ops, and
> may call drm_panel_prepare() and related functions a bit differently. We won't
> be able to use drm_panel_bridge for those drivers.
> 
> For msm, we check whether the DSI encoder is connected directly to a panel
> or an external bridge. If it's connected to an external bridge, we skip the
> creation of the stub connector, and rely on the external bridge driver to
> create the connector:
> 
> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L227
> 
> The msm solution isn't very neat, but it avoids the need to create another
> bridge to glue things together.

Since I suggested this, yes I like it. And I think just unconditionally
creating the panel bridge is probably even simpler, after all bridges are
supposed to be chainable. I guess there's always going to be drivers where
we need special handling, but I'm kinda hoping that for most cases simply
plugging in a panel bridge is all that's need to glue drm_panel support
into a driver. The simple pipe helpers do support bridges, and part of the
goal there very much was to make it easy to glue in panel drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Archit Taneja <architt@codeaurora.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Yannick Fertre <yannick.fertre@st.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
Date: Wed, 3 May 2017 11:32:17 +0200	[thread overview]
Message-ID: <20170503093217.shqduwoq7j6ag4jc@phenom.ffwll.local> (raw)
In-Reply-To: <dfa5416a-ea7f-f3f3-4d63-d80b9fab443d@codeaurora.org>

On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> +panel/bridge reviewers.
> 
> This does make things much cleaner, but it seems a bit strange to create
> a drm_bridge when there isn't really a HW bridge in the display chain (i.e,
> when the DSI encoder is directly connected to a DSI panel).
> 
> There are kms drivers that use drm_panel, but don't have simple stub connectors
> that wrap around a drm_panel. They have more complicated connector ops, and
> may call drm_panel_prepare() and related functions a bit differently. We won't
> be able to use drm_panel_bridge for those drivers.
> 
> For msm, we check whether the DSI encoder is connected directly to a panel
> or an external bridge. If it's connected to an external bridge, we skip the
> creation of the stub connector, and rely on the external bridge driver to
> create the connector:
> 
> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L227
> 
> The msm solution isn't very neat, but it avoids the need to create another
> bridge to glue things together.

Since I suggested this, yes I like it. And I think just unconditionally
creating the panel bridge is probably even simpler, after all bridges are
supposed to be chainable. I guess there's always going to be drivers where
we need special handling, but I'm kinda hoping that for most cases simply
plugging in a panel bridge is all that's need to glue drm_panel support
into a driver. The simple pipe helpers do support bridges, and part of the
goal there very much was to make it easy to glue in panel drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-05-03  9:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 16:36 [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge Eric Anholt
2017-04-27 16:36 ` Eric Anholt
2017-04-27 16:36 ` [PATCH 2/2] drm/vc4: Switch to using the panel-bridge layer, and support bridges Eric Anholt
2017-04-27 16:36   ` Eric Anholt
2017-04-27 17:27 ` [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge Eric Anholt
2017-04-27 17:27   ` Eric Anholt
2017-05-03  9:23 ` Archit Taneja
2017-05-03  9:23   ` Archit Taneja
2017-05-03  9:32   ` Laurent Pinchart
2017-05-03  9:32     ` Laurent Pinchart
2017-05-03  9:32   ` Daniel Vetter [this message]
2017-05-03  9:32     ` Daniel Vetter
2017-05-03  9:36     ` Laurent Pinchart
2017-05-03  9:36       ` Laurent Pinchart
2017-05-03 14:28       ` Daniel Vetter
2017-05-03 14:28         ` Daniel Vetter
2017-05-03 14:44         ` Laurent Pinchart
2017-05-03 14:44           ` Laurent Pinchart
2017-05-03 16:17           ` Eric Anholt
2017-05-03 16:17             ` Eric Anholt
2017-05-04  5:44             ` Daniel Vetter
2017-05-04  5:44               ` Daniel Vetter
2017-05-04 12:35               ` Thierry Reding
2017-05-04 12:35                 ` Thierry Reding
2017-05-05  6:22                 ` Andrzej Hajda
2017-05-05  6:22                   ` Andrzej Hajda
2017-05-03 16:30   ` Eric Anholt
2017-05-03 16:30     ` Eric Anholt
2017-05-04  8:58     ` Archit Taneja
2017-05-04  8:58       ` Archit Taneja
2017-05-03  9:36 ` Daniel Vetter
2017-05-03  9:36   ` Daniel Vetter

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=20170503093217.shqduwoq7j6ag4jc@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=architt@codeaurora.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=treding@nvidia.com \
    --cc=yannick.fertre@st.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.