lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 1 Aug 2022 07:15:07 -0500
From:   Adam Ford <aford173@...il.com>
To:     Marco Felsch <m.felsch@...gutronix.de>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        Marek Vasut <marex@...x.de>, Stefan Agner <stefan@...er.ch>,
        Fabio Estevam <festevam@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Jonas Karlman <jonas@...boo.se>,
        David Airlie <airlied@...ux.ie>,
        Robert Foss <robert.foss@...aro.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Neil Armstrong <narmstrong@...libre.com>,
        NXP Linux Team <linux-imx@....com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Jagan Teki <jagan@...rulasolutions.com>
Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors

On Mon, Aug 1, 2022 at 5:54 AM Adam Ford <aford173@...il.com> wrote:
>
> On Mon, Aug 1, 2022 at 1:20 AM Marco Felsch <m.felsch@...gutronix.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

Powered by blists - more mailing lists