On Wed, Apr 30, 2014 at 8:25 PM, AJAY KUMAR RAMAKRISHNA SHYMALAMMA < ajaykumar.rs at samsung.com> wrote:
> > > > > ------- *Original Message* ------- > > *Sender* : Sean Paul<seanpaul at chromium.org> > > *Date* : Apr 30, 2014 02:34 (GMT+05:30) > > *Title* : Re: [RFC 0/2] drm/bridge: panel and chaining > > > On Tue, Apr 29, 2014 at 3:57 PM, Rob Clark wrote: > > 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. > > Arbitrarily chaining bridges seems like a more robust solution to me > than the composite bridge. > > For the panel case, I wonder if we could change drm_bridge_init to > accept a panel, then we could just chain the panel calls off the > various places the bridge hooks are invoked in the drm layer. > This idea originated from Rob itself. He wanted to move out drm_panel calls from both ptn3460 and ps8622 drivers and he wanted them at a common place. But Daniel suggested that having a chain of bridges is good. That is how composite_bridge was formed. I still think we are addressing a very simple problem in a complex manner. I tried testing this patchset on my board, with some tweaks(explained in PATCH 2/2]), and I could get it working. This code basically adds 3 bridge structures to handle the calls, but in actual hardware you can map them to only one bridge device. I am still not sure what's the problem in just having the panel calls around the bridge calls in drm core? > Feel free to ignore if this has already been explored on the other > thread (which I haven't been following). > > Sean > > > > > > > > > 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 > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/3d43c1f4/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201404302024637_QKNMBDIF.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140430/3d43c1f4/attachment-0001.gif>