How to support various hardware blocks in drm driver
Inki Dae
inki.dae at samsung.com
Tue Mar 18 03:48:39 PDT 2014
Thanks for comments,
2014-03-18 19:27 GMT+09:00 Daniel Vetter <daniel at ffwll.ch>:
> 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).
>
Can the encoder_slave provide interfaces for controlling block devices
that receive output of crtc device? I don't see this encoder_slave can
do it. And my opinion is just to extend existing common frameworks,
drm_panel and drm_bridge. They have already been merged to mainline,
aren't they?
And I understood the encoder_slave is useful for external I2C encoders
so I think it wouldn't be a proper framework for supporting various hw
blocks between display controller and lcd panel, and It seems that the
encoder_slave is specific to desktop device, graphics card.
I really hope you would look into entire contents of my email and give
me your opinion if not yet.
And if there is my missing point, please kindly let me know.
Thanks,
Inki Dae
> 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 at 1 {
>> ...
>> lvds_bridge_0: endpoint {
>> remote-endpoint=<&mipi_dsi_1>;
>> };
>> port at 2 {
>> lvds_bridge_1: endpoint {
>> remote-endpoint=<&panel_0>;
>> };
>> };
>> };
>>
>> mipi-dsi {
>> ...
>> port at 1 {
>> ...
>> mipi_dsi_0: endpoint {
>> remote-endpoint=<&image_enhancement_1>;
>> };
>> };
>> port at 2 {
>> ...
>> mipi_dsi_1: endpoint {
>> remote-endpoint=<&lvds_bridge_0>;
>> };
>> };
>> };
>>
>> image_enhancement {
>> port at 1 {
>> image_enhancement_0: endpoint {
>> remote-endpoint=<&display_controller_0>;
>> };
>> };
>> port at 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 at lists.freedesktop.org
>> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
More information about the dri-devel
mailing list