On Tue, Mar 18, 2014 at 05:26:42PM +0900, Inki Dae wrote:
> Hello all,
>
> The purpose of this email is for discussion to how we could support
> various hardware blocks such as LVDS bridges, Image Enhancement chips
> and parallel panels in drm driver.
>
> Now we have drm_panel framework for controlling parallel panels, and
> drm_bridge for controlling LVDS bridge devices.
> However, drm_panel has only some callbacks, enable, disable and
> get_modes, and drm_bridge has some callbacks only for bridge devices
> so these seems like only for their devices.
>
> However, some SoC could have other type of hardware blocks. i.e. Image
> Enhancement blocks.
> So it seems that these frameworks don't cover all hardware blocks that
> can be placed between Display controller and LCD Panel device.
>
> Below shows various hardware pipe lines for Exynos SoC,
>
> Display Controller-----LCD Panel
> Display Controller-----LVDS Bridge-----LCD Panel
> Display Controller-----MIP DSI-----MIPI TO LVDS Bridge-----LCD Panel
> Display Controller-----Image Enhancement chip-----LCD Panel
> Display Controller-----Image Enhancement chip-----LVDS Bridge-----LCD Panel
> Display Controller-----Image Enhancement chip-----MIP DSI-----MIPI TO
> LVDS Bridge-----LCD Panel
> ...
>
> As you know, these hardware blocks should be probed without the probe
> order issue, and also these hardware blocks should be controlled by
> crtc and connector drivers.
> However, it seems that there is no any good way for this yet. So I
> think we would need a common framework, and for this, we could
> integrate these two frameworks, drm_panel and drm_bridge to one
> integrated framework.
> This integrated framework could be used commonly for other hardware blocks.
>
> Below is just pseudo structure for this,
>
> enum {
> DRM_HW_BLOCK_PANEL,
> DRM_HW_BLOCK_BRIDGE,
> DRM_HW_BLOCK_ENHANCE,
> };
>
> struct drm_hw_block {
> unsigned int type;
> struct device *dev;
> struct drm_device *drm;
>
> /* Used commonly. */
> int (*disable)(struct drm_hw_block *block);
> int (*enable)(struct drm_hw_block *block);
>
> /* For parallel panels. */
> struct drm_connector *connector;
> int (*get_modes)(struct drm_hw_block *block);
>
> /* For LVDS bridge devices. */
> void (*mode_fixup)(struct drm_hw_block *block);
> void (*mode_set)(struct drm_hw_block *block);
> ....
>
> /* For Image Enhancement devices. */
> ....
>
> struct list_head list;
> };
What's the difference here compared to an encoder_slave? I don't really
see the point of adding yet another such thing to the drm core ...
If you don't like the helper libraries provided by the drm core then
either try to improve them, or just roll your own (like i915 does for
modesetting).
Cheers, Daniel
>
> Of course, we could separate above callbacks to each structure like below,
>
> struct drm_panel_funcs {
> ...
> };
>
> struct drm_bridge_funcs {
> ...
> };
>
> struct drm_enhance_funcs {
> ...
> };
>
> struct drm_hw_block {
> unsigned int type;
> ...
> struct drm_panel_funcs *panel_funcs;
> struct drm_bridge_funcs *bridge_funcs;
> struct drm_enhance_funcs *enhance_funcs;
> ...
> };
>
>
> And then what we should consider is how dt of these blocks should be
> bound, and how crtc and connector drivers should control these blocks.
>
> Below is my idea based on super device concept[1] and video interface
> concept[2],
>
> In case of below hardware pipeline:
> Display Controller-----Image Enhancement chip-----MIP DSI-----MIPI TO
> LVDS Bridge-----LCD Panel
>
>
> 1. Bind dt of crtc, connector and block devices, and probe their
> drivers without the probe order issue using below super node and
> component framework,
>
> exynos-drm {
> crtcs = <&display_controller>;
> connectors = <&mip_dsi>;
> blocks = <&image_enhancement>, <&lvds>;
> };
>
> In this pipeline, LCD Panel is a client of MIPI DSI driver so LCD
> Panel will be controlled by mipi dsi driver internally.
> In case of not using MIPI DSI device, connector could be panel like below,
> Display Controller-----Image Enhancement chip-----LCD Panel
>
> exynos-drm {
> crtc = <&display_controller>;
> connectors = <&panel>;
> blocks = <&image_enhancement>
> };
>
>
> 2. Attach block drivers to their corresponding crtc and connector
> drivers using below video interface nodes so that crtc and connector
> drivers can control these block drivers using drm_hw_block object.
>
> panel {
> ...
> port {
> ...
> panel_0: endpoint {
> remote-endpoint=<&lvds_bridge_1>;
> };
> };
> };
>
> lvds-bridge {
> ...
> port@1 {
> ...
> lvds_bridge_0: endpoint {
> remote-endpoint=<&mipi_dsi_1>;
> };
> port@2 {
> lvds_bridge_1: endpoint {
> remote-endpoint=<&panel_0>;
> };
> };
> };
>
> mipi-dsi {
> ...
> port@1 {
> ...
> mipi_dsi_0: endpoint {
> remote-endpoint=<&image_enhancement_1>;
> };
> };
> port@2 {
> ...
> mipi_dsi_1: endpoint {
> remote-endpoint=<&lvds_bridge_0>;
> };
> };
> };
>
> image_enhancement {
> port@1 {
> image_enhancement_0: endpoint {
> remote-endpoint=<&display_controller_0>;
> };
> };
> port@2 {
> image_enhancement_1: endpoint {
> remote-endpoint=<&mipi_dsi_0>;
> };
> };
> };
>
> display-controller {
> port {
> display_controller_0: endpoint {
> remote-endpoint=<&image_enhancement_0>;
> };
> };
> };
>
>
> With above video interface nodes, display controller driver could get
> a drm_hw_block object for controlling image enhancement device, and
> mipi dsi driver could get a drm_hw_block object for controlling lvds
> bridge device.
>
> That is just my idea so maybe there are my missing points, and I'm not
> sure that other SoC drivers have better solutions so If there is any
> better solution, could you please share your idea? If not so, please
> give me your opinions.
>
> I think this time would be a opportunity that we could extend the
> block device support more with a little change.
>
> Thanks,
> Inki Dae
>
>
> [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html
> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
