2014-03-19 6:23 GMT+09:00 Dave Airlie <airlied@xxxxxxxxx>: > On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter <daniel@xxxxxxxx> 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@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. >> >> 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
