Message-ID: <CALAqxLVRsPKv-xmxQfBFaBa9XOmSfrFj3w9_zyfzNJk8+Kfjug@mail.gmail.com>
Date:   Wed, 19 Aug 2020 14:13:05 -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>,
        Xiubin Zhang <zhangxiubin1@...wei.com>,
        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 4:46 AM Mauro Carvalho Chehab
<mchehab+huawei@...nel.org> wrote:
> Yet, I'm submitting it via staging due to the following reasons:
>
> - It depends on the LDO3 power supply, which is provided by
>   a regulator driver that it is currently on staging;
> - Due to legal reasons, I need to preserve the authorship of
>   each one responsbile for each patch. So, I need to start from
>   the original patch from Kernel 4.4;
> - There are still some problems I need to figure out how to solve:
>    - The adv7535 can't get EDID data. Maybe it is a timing issue,
>      but it requires more research to be sure about how to solve it;

I've seen this on the HiKey960 as well. There is a patch to the
adv7533 driver I have to add a mdelay that seems to consistently
resolve the timing problem.  At some point I mentioned it to one of
the maintainers who seems open to having it added, but it seemed silly
to submit it until there was a upstream driver that needed such a
change.  So I think that patch can be submitted as a follow on to this
(hopefully cleaned up) series.

>    - The driver only accept resolutions on a defined list, as there's
>      a known bug that this driver may have troubles with random
>      resolutions. Probably due to a bug at the pixel clock settings;

So, yes, the SoC clks can't generate proper signals for HDMI
frequencies (apparently it's not an issue for panels). There is a
fixed set that we can get "close enough" that most monitors will work,
but its always a bit iffy (some monitors are strict in what they
take).

On the kirin driver, we were able to do a calculation to figure out if
the generated frequency would be close enough:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c#n615

I suspect we could do something similar for the hikey960/70, but I've
not really had time to dig in deeply there.

Personally, I don't see the allow-list as a problematic short term
solution, and again, not sure its worth pushing to staging for.

>    - Sometimes (at least with 1080p), it generates LDI underflow
>      errors, which in turn causes the DRM to stop working. That
>      happens for example when using gdm on Wayland and
>      gnome on X11;

Interestingly, I've not seen this on HiKey960 (at least with
Android/Surfaceflinger). The original HiKey board does have the
trouble where at 1080p the screen sometimes comes up horizontally
offset due to the LDI underflow, but the patches to address it have
been worse then the problem, so we reverted those.

>    - Probably related to the previous issue, when the monitor
>      suspends due to DPMS, it doesn't return back to life.
>

I don't believe I see this on HiKey960. But if it's the LDI issue on
the 970 that may explain it.


> So, IMO, the best is to keep it on staging for a while, until those
> remaining bugs gets solved.

I'm not sure I see all of these as compelling for pushing it in via
staging. And I suspect in the process of submitting the patches for
review folks may find the cause of some of the problems you list here.


> 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
>
>
> Chen Feng (1):
>   staging: hikey9xx: Add hisilicon DRM driver for hikey960/970
>
> John Stultz (1):
>   staging: hikey9xx/gpu: port it to work with Kernel v4.9

Nit: This is a display driver and has little to do with the GPU (other
then it will eventually live in drivers/gpu/drm/...), so I might
suggest using more conventional subject prefix,  "drm: hisilicon:"

thanks
-john

Powered by blists - more mailing lists