2014-03-18 21:22 GMT+09:00 Daniel Vetter daniel@ffwll.ch:
On Tue, Mar 18, 2014 at 1:12 PM, Rob Clark robdclark@gmail.com wrote:
I think the question is how to go from zero or one bridge/hwblock/widget/whatever to zero or more..
an alternate set of helpers is one option. But it didn't turn out to be too intrusive to the existing helpers to add bridge in the first place, so I'm not sure it will be necessary.
I guess we could allow bridges to chain up and have multiple child-bridges or something like that. Plus a helper which finds a suitable routing through this network (it should be a tree after all, so no ambiguity) given a drm_connector/drm_encoder pair. Or maybe I misunderstand what you mean by going from 1 bridge to multiple bridges ...
Daniel,
I think now drm_bridge couldn't do what we want for embedded systems as long as drm_encoder has drm_bridge. See the blow hardware pipeline, Display Controller-----Image Enhancement chip-----MIP DSI-----MIPI TO LVDS Bridge-----LCD Panel
In above hardware pipeline, Display controller is controlled by crtc, and Image Enhancement chip receives output from display controller. So the use of existing drm_bridge would be suitable to only bridge devices between MIPI DSI and LCD Panel, but not to Image Enhancement chip.
For such hardware, drm_panel infrastructure is more reasonable to me, and that is why I try to integrate drm_panel and drm_bridge to one integrated framework which has infrastructure same as existing drm_panel. The important thing is to free this integrated framework from drm_encoder so that crtc device can also use this framework.
Thanks, Inki Dae
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel