Message-ID: <CALAqxLULQvW3UikCHpEzSDnpeYnBy8wDSsWZNbSrmivQTW3_Sg@mail.gmail.com>
Date:   Wed, 19 Aug 2020 20:28:44 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linuxarm@...wei.com, mauro.chehab@...wei.com,
        Manivannan Sadhasivam <mani@...nel.org>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Bogdan Togorean <bogdan.togorean@...log.com>,
        Liwei Cai <cailiwei@...ilicon.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Rob Herring <robh+dt@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Xinliang Liu <xinliang.liu@...aro.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Wanchun Zheng <zhengwanchun@...ilicon.com>,
        driverdevel <devel@...verdev.osuosl.org>,
        BPF Mailing List <bpf@...r.kernel.org>,
        linux-media <linux-media@...r.kernel.org>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Alexei Starovoitov <ast@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Rob Clark <robdclark@...omium.org>,
        Laurentiu Palcu <laurentiu.palcu@....com>,
        Andrzej Hajda <a.hajda@...sung.com>,
        John Fastabend <john.fastabend@...il.com>,
        Liuyao An <anliuyao@...wei.com>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>, Wei Xu <xuwei5@...ilicon.com>,
        Rongrong Zou <zourongrong@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Sam Ravnborg <sam@...nborg.org>,
        Network Development <netdev@...r.kernel.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        David Airlie <airlied@...ux.ie>,
        Chen Feng <puck.chen@...ilicon.com>
Subject: Re: [PATCH 00/49] DRM driver for Hikey 970

On Wed, Aug 19, 2020 at 7:01 PM John Stultz <john.stultz@...aro.org> wrote:
>
> On Wed, Aug 19, 2020 at 2:36 PM John Stultz <john.stultz@...aro.org> wrote:
> >
> > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> > <mchehab+huawei@...nel.org> wrote:
> > > So, IMO, the best is to keep it on staging for a while, until those
> > > remaining bugs gets solved.
> > >
> > > I added this series, together with the regulator driver and
> > > a few other patches (including a hack to fix a Kernel 5.8
> > > regression at WiFi ) at:
> > >
> > >         https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master
> >
> > Sorry, one more small request: Could you create a branch that only has
> > the DRM driver changes in it?
> >
> > The reason I ask, is that since the HiKey960 isn't affected by the
> > majority of the problems you listed as motivation for going through
> > staging. So if we can validate that your tree works fine on HiKey960,
> > the series can be cleaned up and submitted properly upstream to enable
> > that SoC, and the outstanding 970 issues can be worked out afterwards
> > against mainline.
>
> Just as a heads up, I tried testing your tree with my HiKey960, and
> after fixing the compat string inconsistency, the drivers seem to load
> properly. However the drm_hwcomposer seems to have some trouble with
> the driver:
> 01-01 00:12:41.456   345   345 E hwc-drm-display-compositor: Commit
> test failed for display 0, FIXME
> 01-01 00:12:41.456   345   345 E hwc-drm-two: Failed to apply the
> frame composition ret=-22
> 01-01 00:12:41.456   351   351 E HWComposer:
> presentAndGetReleaseFences: present failed for display 0: BadParameter
> (4)
>
> I'll dig in a bit further as to why, but wanted to give you a heads up.

Ok, I've mostly gotten it sorted out:
  - You're missing a few color formats.
  - And I re-discovered a crash that was already fixed in my tree.

I'll send those patches in a few here.

That said even with the patches I've got on top of your series, I
still see a few issues:
1) I'm seeing red-blue swap with your driver.  I need to dig a bit to
see what the difference is, I know gralloc has a config option for
this, and maybe the version of the driver I'm carrying has it wrong?
2) Performance is noticeably worse. Whereas with my tree, I see close
to 60fps (that clk issue we mentioned earlier is why it's not exactly
60) in most tests, but with yours it mostly hovers around 30some fps,
occasionally speeding up to 40 and then back down.

Obviously with some work I suspect we'll be able to sort these out,
but I also do feel that the set you're starting with for upstreaming
is pretty old. The driver I'm carrying was heavily refactored around
5.0 to share code with the existing kirin driver, in the hopes of
making usptreaming easier, and it seems a shame to throw that out and
focus your efforts on the older tree.

But to be fair, I've not had time to upstream the driver myself, and
it's obviously your choice on how you spend your time.  I am really
excited to see your efforts here, regardless of which driver you end
up pushing.

thanks
-john

Powered by blists - more mailing lists