How to support various hardware blocks in drm driver

[Rob Clark]

On Tue, Mar 18, 2014 at 11:22 AM, Inki Dae <inki.dae at samsung.com> wrote:
> 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.

I guess I'm not entirely clear on why each couldn't be a drm_bridge..
I mean, there are probably some other parameters between them, ie. the
mipi2lvds bridge would somehow (via phandle, I assume) get a link to
the 'struct mipi_dsi_device' ptr from the mipi-dsi node.

Obviously we need to add a way to chain up multiple "bridges", but
that was already the rough plan, and just waiting for an upstream
use-case and someone to implement it ;-)

> 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.

well, I'm having trouble coming to grips with what it means to have a
.get_modes() fxn ptr on something which isn't at the end of the chain.
 This is what makes me prefer keeping drm_panel as it's own thing.
Possibly drm_panel could be a subclass of drm_bridge/hwblock.. not
sure if that buys us anything or not.

But other than this, and the name (bridge vs hwblock), it sounds like
we are pretty much describing the same thing.

(and I don't really care about the name.. I'll let someone else paint
that bikeshed)

BR,
-R

> 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