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