forked from luck/tmp_suning_uos_patched
862e686ce4
Allow drm_bridge objects to link to each other in order to form an encoder chain. The requirement for creating a chain of bridges comes because the MSM drm driver uses up its encoder and bridge objects for blocks within the SoC itself. There isn't anything left to use if the SoC display output is connected to an external encoder IC. Having an additional bridge connected to the existing bridge helps here. In general, it is possible for platforms to have multiple devices between the encoder and the connector/panel that require some sort of configuration. We create drm bridge helper functions corresponding to each op in 'drm_bridge_funcs'. These helpers call the corresponding 'drm_bridge_funcs' op for the entire chain of bridges. These helpers are used internally by drm_atomic_helper.c and drm_crtc_helper.c. The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of the bridge closet to the encoder, and proceed until the last bridge in the chain is enabled. The same holds for drm_bridge_mode_set/mode_fixup helpers. The drm_bridge_disable/post_disable helpers disable the last bridge in the chain first, and proceed until the first bridge in the chain is disabled. drm_bridge_attach() remains the same. As before, the driver calling this function should make sure it has set the links correctly. The order in which the bridges are connected to each other determines the order in which the calls are made. One requirement is that every bridge in the chain should point the parent encoder object. This is required since bridge drivers expect a valid encoder pointer in drm_bridge. For example, consider a chain where an encoder's output is connected to bridge1, and bridge1's output is connected to bridge2: /* Like before, attach bridge to an encoder */ bridge1->encoder = encoder; ret = drm_bridge_attach(dev, bridge1); .. /* * set the first bridge's 'next' bridge to bridge2, set its encoder * as bridge1's encoder */ bridge1->next = bridge2 bridge2->encoder = bridge1->encoder; ret = drm_bridge_attach(dev, bridge2); ... ... This method of bridge chaining isn't intrusive and existing drivers that use drm_bridge will behave the same way as before. The bridge helpers also cleans up the atomic and crtc helper files a bit. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> |
||
|---|---|---|
| .. | ||
| bridge | ||
| i2c | ||
| ttm | ||
| ati_pcigart.h | ||
| drm_agpsupport.h | ||
| drm_atomic_helper.h | ||
| drm_atomic.h | ||
| drm_cache.h | ||
| drm_core.h | ||
| drm_crtc_helper.h | ||
| drm_crtc.h | ||
| drm_displayid.h | ||
| drm_dp_helper.h | ||
| drm_dp_mst_helper.h | ||
| drm_edid.h | ||
| drm_encoder_slave.h | ||
| drm_fb_cma_helper.h | ||
| drm_fb_helper.h | ||
| drm_fixed.h | ||
| drm_flip_work.h | ||
| drm_gem_cma_helper.h | ||
| drm_gem.h | ||
| drm_global.h | ||
| drm_hashtab.h | ||
| drm_legacy.h | ||
| drm_mem_util.h | ||
| drm_mipi_dsi.h | ||
| drm_mm.h | ||
| drm_modes.h | ||
| drm_modeset_lock.h | ||
| drm_of.h | ||
| drm_os_linux.h | ||
| drm_panel.h | ||
| drm_pciids.h | ||
| drm_plane_helper.h | ||
| drm_rect.h | ||
| drm_sysfs.h | ||
| drm_vma_manager.h | ||
| drmP.h | ||
| exynos_drm.h | ||
| gma_drm.h | ||
| i915_component.h | ||
| i915_drm.h | ||
| i915_pciids.h | ||
| intel-gtt.h | ||