How to support various hardware blocks in drm driver

[Inki Dae]

2014-03-19 6:23 GMT+09:00 Dave Airlie <airlied at gmail.com>:
> On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae 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.
>>
>> To me this sounds like you simply need to expose all these capabilities to
>> userspace as crtc properties. Which addresses one part of this issue.
>>
>> The other side is how you are going to track this in the driver, and there
>> you can do whatever you want - just add a pointer/structure to the exynos
>> crtc structure for the display enhancement block.
>>
>> The MIPI DSI block would then be treated as a drm_encoder, and all the
>> later stages as drm_bridges up to the very last (the actual lvds panel)
>> which would be a simple drm_panel.
>>
>> I don't really see what additional complexity you need here. Especially
>> since this image enhancer is on your SoC (and I guess a samgsung IP block
>> not shared with any other SoC manufacture) you can easily keep the driver
>> code for it in the exynos driver. So really no need to have a generic
>> interface here.
>
> I'm with Daniel, this does sound like its just part of the "crtc"
> object, just write code in the driver
> to support it and tie it into the crtc.
>

That is really what I try to do just using generic framework, the
integrated drm_bridge framework. We have really been using drm_panel,
drm_bridge and maybe encoder_slave for this. But they are not perfect
yet so I am trying to enhance these frameworks.

Thanks,
Inki Dae

> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel