Re: [PATCH v2 3/3] phy: Add driver for mixel dphy found on imx8

["Guido Günther" <agx@sigxcpu.org>]

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