<div class="gmail_quote">2012/12/18 Daniel Vetter <<a href="mailto:daniel@ffwll.ch" target="_blank">daniel@ffwll.ch</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <<a href="mailto:rob.clark@linaro.org">rob.clark@linaro.org</a>> wrote: >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx </div>Yeah, I guess having a v4l device also exported by the same driver that exports the drm interface might make sense in some cases. But in many cases I think the video part is just an independent IP block and shuffling data around with dma-buf is all we really need. So yeah, I guess sharing display resources between v4l and drm kms driver should be a last resort option, since coordination (especially if it's supposed to be somewhat dynamic) will be extremely hairy. </blockquote><div> I think the one reason that the CDF was appeared is to avoid duplicating codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to avoid ordering issue. And for this, those should be re-implemented in based on drm framework so that those could be treated as all one device. Actually, in case of Exynos, some guys tried to duplicate eDP driver into exynos drm framework in same issue. So I think the best way is to avoid duplicating codes and resolve ordering issue such as s/r operations between all the various components. And the below is my opinion, ----------------------------------------------------- Display Controller-------------CDF---------------|MIPI-DSI/DBI---------------LCD Panel| ----------------------------------------------------- 1. to access MIPI-DSI/DBI and LCD Panel drivers. - Display Controller is controlled by linux framebuffer or drm kms based specific drivers like now. And each driver calls some interfaces of CDF. 2. to control the power of these devices. - drm kms based specific driver calls dpms operation and next the dpms operation calls fb blank operation of linux framebuffer. But for this, we need some interfaces that it can connect between drm and linux framebuffer framework and you can refer to the below link. <a href="http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html">http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html</a> - linux framebuffer based driver calls fb blank operation. fb blank(fb)------------------pm runtime(fb)--------------------fb_blank----------mipi and lcd dpms(drm kms)------------pm runtime(drm kms)----------fb_blank----------mipi and lcd 3. suspend/resume - pm suspend/resume are implemented only in linux framebuffer or drm kms based specific drivers. - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank interfaces. s/r(fb)-----------------------------------------------pm runtime(fb)----------------fb blank-------mipi and lcd s/r(drm kms)--------dpms(drm kms)-------pm runtime(drm kms)------fb_blank------mipi and lcd We could resolve ordering issue to suspend/resume simply duplicating relevant drivers but couldn't avoid duplicating codes. So I think we could avoid the ordering issue using fb blank interface of linux framebuffer and also duplicating codes. Thanks, Inki Dae </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - <a href="http://blog.ffwll.ch" target="_blank">http://blog.ffwll.ch</a> <div class="HOEnZb"><div class="h5">-- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to <a href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</a> More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html" target="_blank">http://vger.kernel.org/majordomo-info.html</a> </div></div></blockquote></div>