On Tue, May 28, 2019 at 8:15 PM Rob Clark <robdclark@xxxxxxxxx> wrote: > > 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.. That was an irc discussion, and I've changed my mind on that. My big issue ended up being that autorefresh was enabled (which basically turns the command panel into a pseudo video mode panel), which appears incompatible with using the start kick. If FW is configuring things in autorefresh mode, the driver likely doesn't know, and will make a mess of things by using the start kick. Disabling autorefresh would make the driver work as is, but fbcon wouldn't work well (you'd need to do a start kick per frame, which doesn't seem to happen). Removing the start kick and using the autorefresh feature seemed better in my testing, but I haven't cleaned up my code tree to send something up. However, lets see how the hardware is actually configured in Brian's case.
