Re: [PATCH RFC 0/8] Add New DRM Driver for Hisilicon's Hi6220 SoC

From: Daniel Vetter <daniel@ffwll.ch>
To: Xinliang Liu <xinliang.liu@linaro.org>
Cc: Yinshengbao <yinshengbao@hisilicon.com>,
	Yiping Xu <xuyiping@hisilicon.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Yanhaifeng <yanhaifeng@hisilicon.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Green <andy.green@linaro.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Dechun Fang <fangdechun@hisilicon.com>,
	puck.chen@hisilicon.com, Yangminglei <ml.yang@hisilicon.com>,
	gongyu@hisilicon.com, xuwei5@hisilicon.com,
	"Liguozhu (Kenneth)" <liguozhu@hisilicon.com>,
	qijiwen@hisilicon.com,
	"Yanglong (James)" <james.yanglong@hisilicon.com>,
	Haojian Zhuang <haojian.zhuang@linaro.org>
Subject: Re: [PATCH RFC 0/8] Add New DRM Driver for Hisilicon's Hi6220 SoC
Date: Tue, 22 Sep 2015 10:49:15 +0200	[thread overview]
Message-ID: <20150922084915.GS3383@phenom.ffwll.local> (raw)
In-Reply-To: <CAGd==05NKAjH=hD=bqKNh052ff=osJ4WxwOdDb3xoC1Mgy6Jdg@mail.gmail.com>

On Thu, Sep 17, 2015 at 05:51:28PM +0800, Xinliang Liu wrote:
> On 17 September 2015 at 04:16, Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Wed, Sep 16, 2015 at 04:23:35PM +0100, Daniel Stone wrote:
> > > The biggest issue though, is that this driver should become an atomic
> > > modesetting driver. Atomic modesetting, rather than sending small
> > > individual commands (enable CRTC, change plane position, etc) is based
> > > on validating and passing around complete sets of hardware state.
> > > Daniel Vetter's blog has an article on how to convert your driver:
> > > http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
> >
> > Yeah, any new driver should really be built on top of atomic - it's a lot
> > more flexible than the old thing and it's also what you want long-term.
> >
> > I've also just done a presenation about atomic for drivers:
> >
> > http://people.freedesktop.org/~danvet/presentations/xdc-2015.pdf
> 
> 
> Hi Daniel,
> This is a good presentation. It gives us very detail and good suggection on
> implementation.
> Thank you for sharing this.
> 
> We have a open source KMS hwc:
> wiki:
> https://wiki.linaro.org/BenjaminGaignard/HWComposer_DRM?highlight=%28hwcomposer%2
> source code: git://git.linaro.org/people/benjamin.gaignard/hwcomposer.git
> Now only STI and Hikey boards are tested on it. And atomic mode setting is
> not support now.
> I think we should add support for atomic mode setting next.
> 
> One difficulty I am facing is that one setting should be made sure is ok in
> the prepare function of hwc.
> If not, the set function of hwc may be fail and display will not properly.
> I don't know atomic mode setting how to handle this situation. And it seems
> that in the prepare function,
> it should check the hardware's capabilities, such as clip, scale, rotation,
> blending and so on.

Specifically to support things like hwc's ->prepare callback atomic
supports a TEST_ONLY mode. Hence in your the prepare code build up the
atomic state, but set the TEST_ONLY flag when calling the ioctl. When the
kernel is happy you can store it somewhere and tell surface flinger the
configuration so it can render the remaining buffers with GL. The idea is
that generic userspace does use TEST_ONLY mode iterative to build up the
maximal configuration of hw planes that a given kms driver supports,
leaving no hw-specific code in userspace. For optimized hwc drivers
running on atomic you then just need to tune the selection, but detailed
constraint checking would still be done by the kernel.

The weston patches from Daniel Stone have a similar design, would be worth
checking those out.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel