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

[Xinliang Liu]

On 22 September 2015 at 01:49, Daniel Vetter <daniel at ffwll.ch> wrote:

> On Thu, Sep 17, 2015 at 05:51:28PM +0800, Xinliang Liu wrote:
> > On 17 September 2015 at 04:16, Daniel Vetter <daniel at 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.
>

​Oh, that's great!​ This sounds a great way. That might solve my problem.
I'll try. Thanks.

​Best,
-Xinliang
​

>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150924/ffb7c090/attachment.html>