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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190529011705.GA12977@basecamp>
Date:   Tue, 28 May 2019 21:17:05 -0400
From:   Brian Masney <masneyb@...tation.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
        MSM <linux-arm-msm@...r.kernel.org>,
        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 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.

Brian