2014-03-18 22:29 GMT+09:00 Rob Clark <robdclark@xxxxxxxxx>: > On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae <inki.dae@xxxxxxxxxxx> wrote: >> 2014-03-18 21:47 GMT+09:00 Daniel Vetter <daniel@xxxxxxxx>: >>> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae <inki.dae@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
