Re: [RFC v2 0/5] Common Display Framework

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Inki,

On Tuesday 18 December 2012 18:38:31 Inki Dae wrote:
> 2012/12/18 Daniel Vetter <daniel@ffwll.ch>
> > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark <rob.clark@linaro.org> 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
> > 
> > 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.
> 
> 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.
> 
> http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html

(Just FYI, I plan to clean up the backlight framework when I'll be done with 
CDF, to remove the FBDEV dependency)

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

As I mentioned before, we have multiple ordering issues related to suspend and 
resume. Panels and display controllers will likely want to enforce a S/R order 
on the video bus, and control busses will also require a specific S/R order. 
My plan is to use early suspend/late resume in the display controller driver 
to control the video busses, and let the PM core handle control bus ordering 
issues. This will of course need to be prototyped and tested.

-- 
Regards,

Laurent Pinchart