lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170503093217.shqduwoq7j6ag4jc@phenom.ffwll.local>
Date:   Wed, 3 May 2017 11:32:17 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Archit Taneja <architt@...eaurora.org>
Cc:     Eric Anholt <eric@...olt.net>, dri-devel@...ts.freedesktop.org,
        Yannick Fertre <yannick.fertre@...com>,
        Thierry Reding <treding@...dia.com>,
        linux-kernel@...r.kernel.org,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the
 lvds-encoder bridge.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ