[RFC 0/2] drm/bridge: panel and chaining

[Inki Dae]

Hi Rob,

> -----Original Message-----
> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
> Of Rob Clark
> Sent: Wednesday, April 30, 2014 4:58 AM
> To: dri-devel at lists.freedesktop.org
> Cc: Ajay Kumar
> Subject: [RFC 0/2] drm/bridge: panel and chaining
> 
> So I thought it would be easier to explain what I had in mind regarding
> Ajay's patchset (to add panel support) in patch form.  Originally Thierry
> had some concerns with adding panel support in bridges ad-hoc.  So this
> idea adds the support of chaining multiple bridges, one of which may be a
> panal adapter (maybe I should have called it drm_panel_adapter_bridge).
> There are a few rough edges and TODOs, it isn't trying to be complete yet.
> 
> So the one question is about that hunk I had to move in ptn3460 from
> pre_enable() to enable().  If that really needs to come before the encoder
> and after the panel, then we should go for a slightly different approach
> instead: add a 'struct drm_bridge *next' ptr in 'struct drm_bridge'.  Then
> each bridge implementation is responsible to call the next in the chain
> (if not null) at the appropriate points.  That gives a bit more
> flexibility to bridges to have something both pre and post the downstream
> bridge/panel in each of the pre/enable/disable/post steps.
> 

I think there would be better idea than chaining multiple bridges. For this,
we had already discussed it[1], and I had posted relevant patch[2] for RFC.

My idea was that encoder driver has one or two bridge objects - for panel
and lvds, and also image enhancer for crtc driver. The integrated drm_bridge
structure including callback set for them. Originally, it was called
"drm_hw_block" but would be reasonable to change to "drm_bridge" and
existing drm_bridge relevant codes should be removed.

The important thing in my approach is that the integrated drm_bridge
structure uses existing drm_panel infrastructure. The reason I did so was
for that bridge device drivers such as lvds and image enhancer could comply
with driver-model - now bridge drivers are non driver-model driver so
encoder drivers should call some function directly to initialize the bridge
driver. e.g. ptn3460_init function.

And also with this approach crtc drivers could control bridge device such as
image enhancer - Image enhancer can be placed between crtc and
encoder/connector, and actually Exynos SoC has such hardware.

For this, I'm planning to post next patch series, at least within this
cycle.

[1] http://www.spinics.net/lists/dri-devel/msg55555.html
[2]http://www.spinics.net/lists/dri-devel/msg55658.html


Thanks,
Inki Dae

> 
> Rob Clark (2):
>   drm/bridge: add composite and panel bridges
>   drm/bridge/ptn3460: add panel support
> 
>  drivers/gpu/drm/bridge/Makefile          |   2 +
>  drivers/gpu/drm/bridge/drm_bridge_util.c | 251
> +++++++++++++++++++++++++++++++  drivers/gpu/drm/bridge/drm_bridge_util.h
> |  29 ++++
>  drivers/gpu/drm/bridge/ptn3460.c         |  39 ++++-
>  include/drm/bridge/ptn3460.h             |   6 +-
>  5 files changed, 319 insertions(+), 8 deletions(-)  create mode 100644
> drivers/gpu/drm/bridge/drm_bridge_util.c
>  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h
> 
> --
> 1.9.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel