Date:	Tue, 22 Sep 2015 10:49:15 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Xinliang Liu <xinliang.liu@...aro.org>
Cc:	Daniel Stone <daniel@...ishbar.org>,
	Xinwei Kong <kong.kongxinwei@...ilicon.com>,
	Yinshengbao <yinshengbao@...ilicon.com>,
	Yiping Xu <xuyiping@...ilicon.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Yanhaifeng <yanhaifeng@...ilicon.com>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Green <andy.green@...aro.org>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Dechun Fang <fangdechun@...ilicon.com>,
	puck.chen@...ilicon.com, Yangminglei <ml.yang@...ilicon.com>,
	gongyu@...ilicon.com, xuwei5@...ilicon.com,
	"Liguozhu (Kenneth)" <liguozhu@...ilicon.com>,
	qijiwen@...ilicon.com,
	"Yanglong (James)" <james.yanglong@...ilicon.com>
Subject: Re: [PATCH RFC 0/8] Add New DRM Driver for Hisilicon's Hi6220 SoC

On Thu, Sep 17, 2015 at 05:51:28PM +0800, Xinliang Liu wrote:
> On 17 September 2015 at 04:16, Daniel Vetter <daniel@...ll.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists