Hi Rob, > -----Original Message----- > From: dri-devel [mailto:dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf > Of Rob Clark > Sent: Wednesday, April 30, 2014 4:58 AM > To: dri-devel@xxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
