linux-kernel - Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 May 2019 19:14:50 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Brian Masney <masneyb@...tation.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Sean Paul <sean@...rly.run>,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        Dave Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jonathan Marek <jonathan@...ek.ca>,
        Rob Herring <robh@...nel.org>
Subject: Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support

On Tue, May 28, 2019 at 6:17 PM Brian Masney <masneyb@...tation.org> wrote:
>
> On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > On Thu, May 9, 2019 at 4:04 AM Brian Masney <masneyb@...tation.org> wrote:
> >
> > > Here is a patch series that adds initial display support for the LG
> > > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > > of these patches are RFC until we can get it fully working.
> > >
> > > The phones boots into terminal mode, however there is a several second
> > > (or more) delay when writing to tty1 compared to when the changes are
> > > actually shown on the screen. The following errors are in dmesg:
> >
> > I tested to apply patches 2-6 and got the console up on the phone as well.
> > I see the same timouts, and I also notice the update is slow in the
> > display, as if the DSI panel was running in low power (LP) mode.
> >
> > Was booting this to do some other work, but happy to see the progress!
>
> Thanks!
>
> I've had three people email me off list regarding the display working on
> 4.17 before the msm kms/drm driver was converted to the DRM atomic API so
> this email is to get some more information out publicly.
>
> I pushed up a branch to my github with 15 patches applied against 4.17
> that has a working display:
>
> https://github.com/masneyb/linux/commits/display-works-4.17
>
> It's in low speed mode but its usable. The first 10 patches are in
> mainline now and the last 5 are in essence this patch series with the
> exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
> There's a slightly different version of that patch in mainline now.
>
> I'm planning to work on the msm8974 interconnect support once some of
> the outstanding interconnect patches for the msm kms/drm driver arrive
> in mainline. I'd really like to understand why the display works on
> 4.17 with those patches though. I assume that it's related to the
> vblank events not working properly? Let me preface this with I'm a
> total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
> looking for these events in the atomic commits before the migration?
> See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
> helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
> call that was added.

interconnect probably good to get going anyways (and I need to find
some time to respin those mdp5/dpu patches) but I guess not related to
what you see (ie. I'd expect interconnect issue would trigger
underflow irq's)..

I'm not entirely sure why atomic would break things but cmd mode
panels aren't especially well tested.  I can't find it now but there
was a thread (or IRC discussion?) that intf2vblank() should be
returning MDP5_IRQ_PING_PONG_<n>_DONE instead of
MDP5_IRQ_PING_PONG_<n>_RD_PTR, which seems likely and possibly related
to vblank timing issues..

BR,
-R



>
> Brian