imx8mm lcdif->dsi->adv7535 no video, no errors

[Adam Ford]

On Mon, Aug 1, 2022 at 5:54 AM Adam Ford <aford173 at gmail.com> wrote:
>
> On Mon, Aug 1, 2022 at 1:20 AM Marco Felsch <m.felsch at pengutronix.de> wrote:
> >
> > Hi Adam,
> >
> > On 22-07-30, Adam Ford wrote:
> > > Hey all,
> > >
> > > I am trying to test Jagan's patch series [1] to add support for the
> > > samsung dsim bridge which is used on the imx8mm to output DSI video.
> > > The DSIM gets the video from the mxsfb, and in my case, the DSI is
> > > sent to the adv7535 for connecting to HDMI.
> >
> > So you're using the NXP recommended evalboard setup :)
>
> Yes and no.  Our design also adds audio to theADV7535 in addition to
> the video signal.
> For the 8M Plus design, we're looking to see if there are any 4K
> DSI->HDMI bridge chips available.
>
> >
> > > I have been able to get the device tree setup and I don't get any
> > > errors.  The Linux system appears to think the video is connected as
> > > determined by modetest:
> >
> > ...
> >
> > > Unfortunately, there is no video in my monitor, and my monitor states
> > > there is no signal.
> >
> > This is pretty much known, at least on our side. We also have a few more
> > patches on top of the series [1] for fixing the horizontal porches.  Our
> > current status is that we can get only one mode out of the ADV7535 which
> > is 1080P. Our assumption is that the ADV7535 needs some attentions
> > (fixes) but we can't verify that since the documentation is under NDA.
>
> I am glad I am not alone.   Thanks for the tip.  That gives me
> something to investigate.
> >
> > > If I use NXP's downstream kernel, this same hardware configuration
> > > works fine and I can see the video.
> >
> > This is because of the NXP downstream kernel porch 'calculation' and
> > workarounds. The values they are using for calculation don't take any
> > mode values into account and instead they are using a table. We don't
> > know where those values come from.
>
> I would think the VESA group would have something like these published.
> >
> > > I have checked the clk_summary, and the working and non-working
> > > conditions both have clock rates that are the same for DSI, LCDIF and
> > > related items.  The power domains connected to the lcdif and the dsi
> > > show they are active.
> > >
> > > Since I go no errors, and  Linux looks like it's happy, I was hoping
> > > someone from who better understands the interconnections between all
> > > these bridge layers might be able to offer a suggestion of something
> > > to investigate and/or try.
> > >
> > > The kernel repo I am using is from Jagan located here:
> > >
> > > [1] - https://github.com/openedev/kernel
> > >
> > > I am not convinced it's a device tree issue since I get no errors when
> > > the drivers enumerate, but I can provide my device tree updates if
> > > that helps.
> >
> > Please see above. Our debugging showed that there is a strange behaviour
> > of the ADV7535 but we don't have any documentation.
> Thanks for the comments.
>
> I'll look to see what I have for documentation.  I know my company
> signed a bunch of NDA stuff and we have an HDMI license.  I'll go
> through NXP's patches to their kernel and compare with whatever
> documentation I can find to see if I can make any improvements.

I checked our datasheet vault and I found no programming guide for the
ADV7535.  :-(
I've put in a request to see if we can get one.

I found one for the adv7511 on Analog Device's web site:
https://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Programming_Guide.pdf

They have a table of values for the different resolutions.  I am
guessing they might be the same or similar for 7535.
I'm going to look into NXP's alterations to this driver when I have more time.

adam
>
> adam
> >
> > Regards,
> >   Marco