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 05:54:02 -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 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.

adam
>
> Regards,
>   Marco

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ