On Tue, May 28, 2019 at 6:17 PM Brian Masney <masneyb@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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
