How to support various hardware blocks in drm driver

18 Mar 2014


      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;
};
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

-Daniel

-Daniel

-Daniel