How to support various hardware blocks in drm driver

[Inki Dae]

2014-03-18 22:29 GMT+09:00 Rob Clark <robdclark at gmail.com>:
> On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae <inki.dae at samsung.com> wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter <daniel at ffwll.ch>:
>>> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae <inki.dae at samsung.com> wrote:
>>>> 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.
>>>
>>> Hm, what is this image enhancement chip? Is that some IP block on the
>>> SoC? Is it optional? Can it be attached to different crtcs?
>>
>> In case of Exynos, this chip is in SoC, and can be only attached to
>> one crtc, display controller. But I'm not sure other SoC have similar
>> chip.
>>
>>>
>>> I think we have similar things on intel hardware, but without details
>>> on what it does and how it works I can't really say how to best expose
>>> it to userspace and how to best handle it internally in the driver.
>>> -Daniel
>>
>> Simply saying, the image enhancement chip can enhance image data from
>> display controller, i.e. saturation enhancement, color reproduction,
>> dithering, and so on.
>> And this chip receives image data through hardware wired lines
>> connected internally between display controller and this chip.
>
> I suppose in some sense it doesn't really matter if it is internal
> block or external chip..
>
> but I'm still a bit confused about why you think drm_panel is a better
> fit.. could you explain that part?
>

As I already mentioned, see the below hardware pipeline,
Display Controller-----Image Enhancement chip-----MIPI DSI-----MIPI TO
LVDS Bridge-----LCD Panel

In above pipeline, the only place drm_bridge can exist is in MIPI DSI
driver because drm_encoder and drm_connector should be implemented in
MIPI DSI driver like we did using super node, at least in case of
exynos - it seems that this way is reasonable to me according to super
device and video-interface document.

However, there could be Image Enhancement chip between display
controller and MIPI DSI, and that means we need other thing for
controlling this chip because existing drm_bridge cannot be used for
this.
In the other hands, drm_panel infrastructure could be used by all
device types, crtc or encoder/connector because drm_panel could belong
to any device types.
So I thought it'd better to use existing framework with a little
change than using new one, and we could integrate these two
frameworks, drm_bridge and drm_panel to one framework.

I am planning to integrate them to one framework, and remove existing
drm_bridge. As a result, it would exist only one integrated
drm_bridge.

Is there any way that can control such chip using existing drm_bridge
contained in drm_encoder? if other better way, please give me your
idea.

Thanks,
Inki Dae

> BR,
> -R
>
>> Thanks,
>> Inki Dae
>>
>>> --
>>> 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
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel