linux-kernel - RE: imx8mm lcdif->dsi->adv7535 no video, no errors

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]
Message-ID: <TYCPR01MB59336A94BA5156C49E14578B869F9@TYCPR01MB5933.jpnprd01.prod.outlook.com>
Date:   Thu, 4 Aug 2022 14:43:43 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Adam Ford <aford173@...il.com>,
        Marco Felsch <m.felsch@...gutronix.de>
CC:     Dave Stevenson <dave.stevenson@...pberrypi.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        David Airlie <airlied@...ux.ie>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Marek Vasut <marex@...x.de>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Jagan Teki <jagan@...rulasolutions.com>,
        "robert.chiras@....com" <robert.chiras@....com>,
        "laurentiu.palcu@....com" <laurentiu.palcu@....com>,
        NXP Linux Team <linux-imx@....com>,
        Jonas Karlman <jonas@...boo.se>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Robert Foss <robert.foss@...aro.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>
Subject: RE: imx8mm lcdif->dsi->adv7535 no video, no errors

Hi Adam,

> Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> 
> On Thu, Aug 4, 2022 at 7:52 AM Marco Felsch <m.felsch@...gutronix.de>
> wrote:
> >
> > Hi Dave,
> >
> > On 22-08-04, Dave Stevenson wrote:
> > > Hi Marco
> > >
> > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch <m.felsch@...gutronix.de>
> wrote:
> > > >
> > > > Hi Dave, Adam,
> > > >
> > > > On 22-08-03, Dave Stevenson wrote:
> > > > > Hi Adam
> > > > >
> > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford <aford173@...il.com>
> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > Did managed to get access to the ADV7535 programming guide?
> > > > > > > This is the black box here. Let me check if I can provide
> > > > > > > you a link with our repo so you can test our current DSIM
> state if you want.
> > > > > >
> > > > > > I do have access to the programming guide, but it's under NDA,
> > > > > > but I'll try to answer questions if I can.
> > > > >
> > > > > Not meaning to butt in, but I have datasheets for ADV7533 and
> > > > > 7535 from previously looking at these chips.
> > > >
> > > > Thanks for stepping into :)
> > > >
> > > > > Mine fairly plainly states:
> > > > > "The DSI receiver input supports DSI video mode operation only,
> > > > > and specifically, only supports nonburst mode with sync pulses".
> > > >
> > > > I've read this also, and we are working in nonburst mode with sync
> > > > pulses. I have no access to an MIPI-DSI analyzer therefore I can't
> > > > verify it.
> > > >
> > > > > Non-burst mode meaning that the DSI pixel rate MUST be the same
> > > > > as the HDMI pixel rate.
> > > >
> > > > On DSI side you don't have a pixel-clock instead there is bit-
> clock.
> > >
> > > You have an effective pixel clock, with a fixed conversion for the
> > > configuration.
> > >
> > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate.
> > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s
> >
> > Okay, I just checked the bandwidth which must equal.
> >
> > > As noted elsewhere, the DSI is DDR, so the clock lane itself is only
> > > running at 891 / 2 = 445.5MHz.
> > >
> > > > > Section 6.1.1 "DSI Input Modes" of adv7533_hardware_user_s_guide
> > > > > is even more explicit about the requirement of DSI timing
> > > > > matching
> > > >
> > > > Is it possible to share the key points of the requirements?
> > >
> > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs.
> > > This mode requires real time data generation as a pulse packet
> > > received becomes a pulse generated. Therefore this mode requires a
> > > continuous stream of data with correct video timing to avoid any
> > > visual artifacts."
> > >
> > > LP mode is supported on data lanes. Clock lane must remain in HS
> mode.
> > >
> > > "... the goal is to accurately convey DPI-type timing over DSI. This
> > > includes matching DPI pixel-transmission rates, and widths of timing
> > > events."
> >
> > Thanks for sharing.
> >
> > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would
> > > > > therefore be correct for 720p operation.
> > > >
> > > > It should be absolute no difference if you work on 891MHz with 2
> > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that
> > > > you need the minimum required bandwidth which is roughly:
> > > > 1280*720*24*60 = 1.327 GBps.
> > >
> > > Has someone changed the number of lanes in use? I'd missed that if
> > > so, but I'll agree that 891MHz over 2 lanes should work for 720p60.
> >
> > The ADV driver is changing it autom. but this logic is somehow odd and
> > there was already a approach to stop the driver doing this.
> >
> > To sync up: we have two problems:
> >   1) The 720P mode with static DSI host configuration isn't working
> >      without hacks.
> 
> can you share your hacks with me about getting 720p to work?  I've been
> struggling to get 720 to work.

I have problems with 720p working on 3 lanes. Then I switch to 4 lanes [1]
and it starts working on Renesas RZ/G2L SMARC EVK.

[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220309151109.20957-2-biju.das.jz@bp.renesas.com/

Cheers,
Biju