Hi, On Fri, Feb 08, 2019 at 11:55:41AM +0000, Robert Chiras wrote: > Hi Guido > > On Vi, 2019-02-08 at 12:40 +0100, Guido Günther wrote: > > Hi Robert, > > On Wed, Feb 06, 2019 at 03:28:07PM +0000, Robert Chiras wrote: > > > > > > Hi Guido, > > > > > > Thanks for picking this up. It's interesting to see that a lot has > > > changed in the PHY API and the phy can be now configured through > > > the > > > API instead of exported function as I did in the NXP tree. > > > > > > I was going through your implementation and I noticed you also > > > added > > > the phy_ref clock to this driver too. This is good, since the DPHY > > > needs this clock, but I have a question related to the other > > > clocks: > > > According to the Northwest Logic reference manual (the DSI host > > > that > > > uses this DPHY), the host relies on the TX clock in order to > > > configure > > > the DPHY. Is this driver relying on it's user to also enable the TX > > > clock? > > Yes, I think that would be best. In fact due to lack of reference > > manuals for nwl and mixel I didn't even know exactly which clocks > > needed > > to be on already so I currently set for enabling this after the nwl > > clocks. Are these manuals available publicly somewhere, I couldn't > > find > > them? > > That's OK, I guess. Regarding the manuals: we have them from the vendor > so I can't share them.
Too bad. Any contact I could ping there would also be nice? > > > > > > > > > Also: did you test this driver? Because I have a version of the > > > patches > > > from NXP tree rebased on top of latest linux-next and I have a > > > working > > Hmm...could you (maybe off list) send the boot output with DEBUG 1 > > at the top of the driver and drm.debug=0x2f on the kernel command > > line? > > Maybe I can spot something. > > Eventually I got it working. On i.MX8MQ there is a System Reset > Controller that controls the clocks on each individual block. For some > reason, before asserting the MIPI clock domain in this SRC, a delay is > needed (right now, the hack is a sleep). Probably there is a component > that is not ready yet. Right now I am trying to figure out which one is > it and how can I wait for it. > > > > > > > > > version of eLCDIF with Raydium RM67191 DSI panel on mScale850D > > > (i.MX8MQ). And I tried using this driver but there is no signal on > > > the > > > screen, even through the register values are all identical. Next, > > > I'll > > > try to debug why isn't this working on my setup. > > I'm testing this on the Librem 5 devkit with a rockchip panel atm > > using > > DCSS not eLCDIF though. My plan is to move to the NXP evk in the not > > so > > far future to make this easier to reproduce. > > Good to know. Currently I am working on the eLCDIF pipeline on 850D to > make it ready for upstream. Since you took my DPHY driver and submitted > upstream in a better shape, I will make use of it. Cool. I have an initial version of nwl mostly in shape now too (hope to send it out in a couple of days). eLCDIF will be handy to test the whole stack on 5.x. Cheers, -- Guido _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
