From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B327C00140 for ; Fri, 5 Aug 2022 21:05:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240396AbiHEVFx (ORCPT ); Fri, 5 Aug 2022 17:05:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233731AbiHEVFu (ORCPT ); Fri, 5 Aug 2022 17:05:50 -0400 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C1371DA4E for ; Fri, 5 Aug 2022 14:05:48 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id gb36so6978385ejc.10 for ; Fri, 05 Aug 2022 14:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=7p80Yi4ha4MyJClpDNxOS+05Egu0byNIpa228CYGpOc=; b=nl/5LUuB2pkS9TXIbwBqUrVbyqH6HqLPe8nskNgTbKZ7IUjejMaBU0iGwYkKMSCf4q qVsVuTEFiLVvQ+zcTAqbCFH1CiyPWOo/ojJwEdx93vy9SzsQsvgzWBqAMxkI/BPbRD6u yl2FGnGba0cl7d+3gl2ZwJ4BrOchNvd6WIK9hueCd7LMT+DqK7qzr/eaqV8HGfWRbq+U Ut6Z5vkWx0S0qZFyRHqhK1nmQQmAXH5pjFeEp76hF5i4mIXOfPFBdgCKGsW9XmUpVSaU vX+8m+jNBerR/Lc1mUah98zptzz4A78xBg89DOZ7J3UArdGVKfb9Z38OO3dqcdqnq+s/ ZbwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=7p80Yi4ha4MyJClpDNxOS+05Egu0byNIpa228CYGpOc=; b=T2TzVmZVTNe2JI+nfccOVVYb9ZVrkFL5XUpKDxH1LE4QmudSwNzUnSQ0/6YCo5XpmF 8ZzBR+AvjGdg+z52MnbFMxsXGr278++/PZwHTRNFlgLOAS6DlBADdiBUGGHnpL1x75We NCB+eKzQRcsmZ5OAET3W+IEDKWn7Hu2QOTvC6xSfmJ8DBuGVccwsW0kTWmaYaGhaxVRP +1BQdw+QzO3DKPGVURooNv/NyLLR2Y91FusDjWrzMrbdYBOAgeMEvhAsxMsNrGH0GkMS /m2cc+r2Wv1qsDSfILMYtmq5kDKT2KjaoWrRANONiv34Qg+ABHG45gph7Ck3dj7DmxXK PQ8w== X-Gm-Message-State: ACgBeo2TnXdIR0yzj8UmxmWjuMCcIqW4vVA6B41ALpXRgwmSIrCCY41/ eDLDnIvp42TXjzdPWLCjqK00SR51oirnsLJx6lc= X-Google-Smtp-Source: AA6agR5eVG41whRe1NHXF3sWbALmE2zoW/5IRkdU1cMcXQ1qZaXWCncLfqYPVfsr+qJYNgvMprmisZkYpUcQ95Ypo5E= X-Received: by 2002:a17:907:a428:b0:730:aee3:2da7 with SMTP id sg40-20020a170907a42800b00730aee32da7mr6208248ejc.613.1659733546601; Fri, 05 Aug 2022 14:05:46 -0700 (PDT) MIME-Version: 1.0 References: <20220802080820.jyf3tfpgcj3pvbtp@pengutronix.de> <20220803062024.vn7awasmifkp5xow@pengutronix.de> <20220804093829.42kdelp7u4r743nv@pengutronix.de> <20220804125152.idyzetjqkjzgbbm2@pengutronix.de> In-Reply-To: From: Adam Ford Date: Fri, 5 Aug 2022 16:05:35 -0500 Message-ID: Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors To: Biju Das Cc: Dave Stevenson , Marco Felsch , Neil Armstrong , David Airlie , dri-devel , Laurent Pinchart , Andrzej Hajda , Marek Szyprowski , Marek Vasut , Jernej Skrabec , Jagan Teki , "robert.chiras@nxp.com" , "laurentiu.palcu@nxp.com" , NXP Linux Team , Jonas Karlman , Sascha Hauer , arm-soc , Linux Kernel Mailing List , Robert Foss , Pengutronix Kernel Team , Shawn Guo Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote: > > > > > > Hi Adam and all, > > > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > > > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson > > > > wrote: > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > Hi Marco > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > wrote: > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > 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. > > > > > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes > > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but > > > > > probably the only way it can be achieved in the current framework. > > > > > > > > > > > To sync up: we have two problems: > > > > > > 1) The 720P mode with static DSI host configuration isn't working > > > > > > without hacks. > > > > > > 2) The DSI link frequency should changed as soon as required > > > > > > automatically. So we can provide all modes. > > > > > > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > > > > > > > > > If you change your link frequency, it may be worth trying a lower > > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4 > > > > > lanes is again listed as mandatory for using the timing generator). > > Marco, > > Looking through the DSIM driver that NXP uses, it appears that they > have a few special cases where they intentionally manipulate the DSIM > under certain conditions: > > /* '1280x720@60Hz' mode with 2 data lanes > * requires special fine tuning for DPHY > * TIMING config according to the tests. > */ > > There is also a separate one for the 4-lane mode: > > /* workaround for CEA standard mode "1280x720@60" "1920x1080p24" > * display on 4 data lanes with Non-burst with sync > * pulse DSI mode, since use the standard horizontal > * timings cannot display correctly. And this code > * cannot be put into the dsim Bridge's mode_fixup, > * since the DSI device lane number change always > * happens after that. > */ > > And lastly, they address issues with 3-lane mode: > > /* TODO: DSIM 3 lanes has some display issue, so > * avoid 3 lanes enable, and force data lanes to > * be 2. > */ > > Since the ADV is trying to adjust the lanes to 3 when running at 720p, > it could be part of the reason you need to jump to 2-lane mode. > > > > > > > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as > > > > > > > one of the modes that is mandatory to use the timing generator > > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required. > > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates > > > > > > > and not the base one, as it's only a base clock change with the > > > > > > > same timing (74.176MHz clock instead of 74.25MHz). > > > > > > > > > > > > Interesting! I would like to know how the HDMI block gets fetched by > > > > > > the DSI block and how the timing-generator can influence this in > > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are > > > > sufficient. > > > > > > > > > > > > > > > If you do program the manual DSI divider register to allow a > > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, > > > > > > > > > you'd be relying on > > > > > > > > > > > > > > > > There is no such DSI pixel rate to be precise, we only have a > > > > > > > > DSI bit clock/rate. > > > > > > > > > > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx > > > > > > > > > and HDMI tx to compensate for the differing data rates. I see > > > > > > > > > no reference to such, and I'd be surprised if it was more than > > > > > > > > > a half dozen pixels to compensate for the jitter in the cases > > > > > > > > > where the internal timing generator is mandatory due to > > > > fractional bytes. > > > > > > > > > > > > > > > > This is interesting and would proofs our assumption that the > > > > > > > > device don't have a FIFO :) > > > > > > > > > > > > > > > > Our assumptions (we don't have the datasheet/programming > > > > manual): > > > > > > > > - HDMI part is fetching 3 bytes per HDMI pixclk > > > > > > > > - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI > > > > and > > > > > > > > HDMI are in sync. So from bandwidth pov there are no > > > > differences > > > > > > > > between: > > > > > > > > - HDMI: 74.25 MHz * 24 Bit = 1782.0 MBit/s > > > > > > > > - DSI: 891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: > > > > 445.5 ) > > > > > > > > - DSI: 445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: > > > > > > > > 222.75) > > > > > > > > > > > > > > > > But the ratio is different and therefore the faster clocking > > > > option > > > > > > > > let something 'overflow'. > > > > > > > > > > > > > > I'll agree that all looks consistent. > > > > > > > > > > > > > > > Anyway, but all this means that Adam should configure the > > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this > > > > > > > > doesn't work either and now we are back on my initial statement > > > > > > > > -> the driver needs some attention. > > > > > > > > > > > > > > Things always need attention :-) > > > > > > > > > > > > ^^ > > > > > > > > > > > > > I suspect that it's the use of the timing generator that is the > > > > issue. > > > > > > > The programming guide does recommend using it for all modes, so > > > > > > > that would be a sensible first step. > > > > > > > > > > > > But I tested it without the timing-generator too. Can you or Adam > > > > > > verify the timing-generator diable logic? > > > > > > > > > > Sorry, running without the use of the timing generator is the issue. > > > > > It is mandatory in some modes, but supported in all modes. Always > > > > > using it should therefore avoid not using it in one of the mandatory > > > > > modes (the list looks a little arbitrary). I tested running various modes with the timing generator disable on an NXP kernel with functional video, and some of the video modes stopped operating or became blurry. With the generator on, it appeared to make the issues go away, so I think it should be left on. > > > > > > > > > > > > I will say that we had a number of issues getting this chip to do > > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead > > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite > > > > > > > some assistance from ADI. > > > > > > > > > > > > Even more interessting, what is your alternative to this chip? > > > > > > > > > > BCM2711 which supported dual HDMI natively. > > > > > Our investigation of ADV7535 was when trying to build what became > > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I > > > > > do have the prototype, the ADV was wired up weirdly with I2C so I > > > > > never really got it running with Linux. > > > > > > > > I think I have convinced myself that the DSIM is working good enough to > > > > match that of the NXP. > > > > > > > > I've gone through and made a list of the register differences between a > > > > working display using NXP's kernel and the non-working display. I've > > > > identified a small handful of registers on both the CEC bank of > > > > registers and main set of registers. > > > > > > > > I noticed that the working NXP version doesn't rescale the number of > > > > lanes based on the clock rate, and it stays fixed at 4 lanes. > > > > > > Does it mean theoretically rescale of lanes is not required?? > > > > On the custom kernel from NXP, I can sync at 720p at 4-lanes. > > Unfortunately, I haven't yet been able to replicate all the register > > settings between my working version at 720p and my non-working > > version, and I still have yet to sync at 720p using the mainline > > adv7535 driver. I am still wrokong on it. > > > > > At least 2 platforms can work with fixed 4 lanes@720p. > > Based on what I'm seeing for this NXP platform, it almost seems like > the DSI transmitter should make the determination on whether or not to > scale the number of lanes instead of having the ADV7373 do it. Since > their custom kernel is able to do 720p in 4-lane mode with this part, > it doesn't seem unreasonable to me. I did a bunch of comparisons between registers for both the ADV7535 and the DSIM, and it appears that the video information is somehow different between the working NXP kernel and non-working one. The two main differences are around the values of htotal hfp. Both the DSIM and the ADV7535 are using different values for htotal and the hfp between the kernels. I am wondering if there is a bug in the 5.19 driver which is fetching wrong info or somehow the data isn't being calculated properly because both the DSIM and the ADV timings match each other, but don't match the working kernel. 720p Working on NXP: [ 24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 -> hfp_wc = 78 [ 24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24 [ 24.681496] adv7511_dsi_config_timing_gen: htotal 1652 [ 24.691372] adv7511_dsi_config_timing_gen: hfp 112 720p Not working: [ 106.424404] samsung_dsim_set_display_mode: vfp = 5 [ 106.429216] samsung_dsim_set_display_mode: bfp = 20 [ 106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 -> hfp_wc = 77 [ 106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24 [ 106.456314] LCD size = 1280x720 [ 106.470115] adv7511_dsi_config_timing_gen: htotal = 1650 [ 106.480707] adv7511_dsi_config_timing_gen: hfp = 110 adam > > > > > > > and looks like few platforms have display stability issue working with 4 lanes@720p, > > > so, as a workaround they changed to 3 lanes based on clock rate to make it work. > > > > > > Can you please confirm, is my understanding correct? > > > > That is my understanding. > > > > > > > > Note: > > > On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs > > > different pll parameters to generate the dot clock to work. > > > > The NXP platform I am using also needs to regenerate the clock. From > > what I can tell, it looks like the clock calculation on my board > > appears correct for both > > > > > > Cheers, > > > Biju From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 08A06C00140 for ; Fri, 5 Aug 2022 21:07:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=J+nt1KP++Te4PS7HrZLd9l6S5r9Hjm7dnqKkaFkTGRA=; b=1Utp8vnB8QXndh 5jLo5y5swRVtalMHJzRkI0HFlS051lSTkNZPk6NPwa3SV3MqfsyxjVlhWbscg1OrKgIaW0wGRzkLa ule2fIs5dV0gZB9lCEbvL0qqpujj8TPzDq1uBOnuSUaix4HAfWOc9Dbq3HgMl0t2FTI5VrqE18lf1 HMMmdf0w5aym8fYKgUmfkkWxkggZVzD+O4o+OpSlad33XntFcKrKbM5jTaN0iYuieDc9FeEE6vTdc b+qUeW3djRljqnuCTKTyRVteC2+hty7nJs69knzjmGL/Rdvuxk8k8z6U6nYczz/DXYOiNtFuieeI8 aX2oemNF7d4R/JuhS2EA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oK4W3-000hOw-Ak; Fri, 05 Aug 2022 21:05:55 +0000 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oK4Vz-000hMK-9y for linux-arm-kernel@lists.infradead.org; Fri, 05 Aug 2022 21:05:53 +0000 Received: by mail-ej1-x633.google.com with SMTP id dc19so6950228ejb.12 for ; Fri, 05 Aug 2022 14:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=7p80Yi4ha4MyJClpDNxOS+05Egu0byNIpa228CYGpOc=; b=nl/5LUuB2pkS9TXIbwBqUrVbyqH6HqLPe8nskNgTbKZ7IUjejMaBU0iGwYkKMSCf4q qVsVuTEFiLVvQ+zcTAqbCFH1CiyPWOo/ojJwEdx93vy9SzsQsvgzWBqAMxkI/BPbRD6u yl2FGnGba0cl7d+3gl2ZwJ4BrOchNvd6WIK9hueCd7LMT+DqK7qzr/eaqV8HGfWRbq+U Ut6Z5vkWx0S0qZFyRHqhK1nmQQmAXH5pjFeEp76hF5i4mIXOfPFBdgCKGsW9XmUpVSaU vX+8m+jNBerR/Lc1mUah98zptzz4A78xBg89DOZ7J3UArdGVKfb9Z38OO3dqcdqnq+s/ ZbwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=7p80Yi4ha4MyJClpDNxOS+05Egu0byNIpa228CYGpOc=; b=BvjnLlizC0+xQNjr1ncBkBaN2hKt2qt5MPEi/BqdMcmH9+TTZb9GWYrM3HJxey12JS XG3lFySzscQEMCPK3ymZQRaAmR91rVrDZfYTJD2AQ8HvZLm41AUhrcyvLnXhNsZLgkrw 4fcXwGoGf0/bcIOOItyp4adjoOs+0kG2V/e5iPtlcZltaBRTVfpXLqplrB1fKEOtzgJX jo2AeKH+rBjs5QoUVLnmabgWvnt8oJnKDv4ukgM6Vz5f3h8HNUQJe6Dl1F5FEhf+5JqB w2Ynp9x2tc9ku53XoNmHCmBMq4wPLwEe++Wj5Xf0hdj5HWYd1/Gtf4cnSHJkT3IsnU61 beCg== X-Gm-Message-State: ACgBeo2SUOqUQh4x+RGkub6Fms0ZJYOdoX/cXPLOl57i+SaASEHG1LQO l9c6dzFZmcfYSlvU0eW4Z1BHgMQHvdiMGXoKm0Q= X-Google-Smtp-Source: AA6agR5eVG41whRe1NHXF3sWbALmE2zoW/5IRkdU1cMcXQ1qZaXWCncLfqYPVfsr+qJYNgvMprmisZkYpUcQ95Ypo5E= X-Received: by 2002:a17:907:a428:b0:730:aee3:2da7 with SMTP id sg40-20020a170907a42800b00730aee32da7mr6208248ejc.613.1659733546601; Fri, 05 Aug 2022 14:05:46 -0700 (PDT) MIME-Version: 1.0 References: <20220802080820.jyf3tfpgcj3pvbtp@pengutronix.de> <20220803062024.vn7awasmifkp5xow@pengutronix.de> <20220804093829.42kdelp7u4r743nv@pengutronix.de> <20220804125152.idyzetjqkjzgbbm2@pengutronix.de> In-Reply-To: From: Adam Ford Date: Fri, 5 Aug 2022 16:05:35 -0500 Message-ID: Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors To: Biju Das Cc: Dave Stevenson , Marco Felsch , Neil Armstrong , David Airlie , dri-devel , Laurent Pinchart , Andrzej Hajda , Marek Szyprowski , Marek Vasut , Jernej Skrabec , Jagan Teki , "robert.chiras@nxp.com" , "laurentiu.palcu@nxp.com" , NXP Linux Team , Jonas Karlman , Sascha Hauer , arm-soc , Linux Kernel Mailing List , Robert Foss , Pengutronix Kernel Team , Shawn Guo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220805_140551_400926_EFF63775 X-CRM114-Status: GOOD ( 79.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote: > > > > > > Hi Adam and all, > > > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > > > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson > > > > wrote: > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > Hi Marco > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > wrote: > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > 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. > > > > > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes > > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but > > > > > probably the only way it can be achieved in the current framework. > > > > > > > > > > > To sync up: we have two problems: > > > > > > 1) The 720P mode with static DSI host configuration isn't working > > > > > > without hacks. > > > > > > 2) The DSI link frequency should changed as soon as required > > > > > > automatically. So we can provide all modes. > > > > > > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > > > > > > > > > If you change your link frequency, it may be worth trying a lower > > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4 > > > > > lanes is again listed as mandatory for using the timing generator). > > Marco, > > Looking through the DSIM driver that NXP uses, it appears that they > have a few special cases where they intentionally manipulate the DSIM > under certain conditions: > > /* '1280x720@60Hz' mode with 2 data lanes > * requires special fine tuning for DPHY > * TIMING config according to the tests. > */ > > There is also a separate one for the 4-lane mode: > > /* workaround for CEA standard mode "1280x720@60" "1920x1080p24" > * display on 4 data lanes with Non-burst with sync > * pulse DSI mode, since use the standard horizontal > * timings cannot display correctly. And this code > * cannot be put into the dsim Bridge's mode_fixup, > * since the DSI device lane number change always > * happens after that. > */ > > And lastly, they address issues with 3-lane mode: > > /* TODO: DSIM 3 lanes has some display issue, so > * avoid 3 lanes enable, and force data lanes to > * be 2. > */ > > Since the ADV is trying to adjust the lanes to 3 when running at 720p, > it could be part of the reason you need to jump to 2-lane mode. > > > > > > > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as > > > > > > > one of the modes that is mandatory to use the timing generator > > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required. > > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates > > > > > > > and not the base one, as it's only a base clock change with the > > > > > > > same timing (74.176MHz clock instead of 74.25MHz). > > > > > > > > > > > > Interesting! I would like to know how the HDMI block gets fetched by > > > > > > the DSI block and how the timing-generator can influence this in > > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are > > > > sufficient. > > > > > > > > > > > > > > > If you do program the manual DSI divider register to allow a > > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, > > > > > > > > > you'd be relying on > > > > > > > > > > > > > > > > There is no such DSI pixel rate to be precise, we only have a > > > > > > > > DSI bit clock/rate. > > > > > > > > > > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx > > > > > > > > > and HDMI tx to compensate for the differing data rates. I see > > > > > > > > > no reference to such, and I'd be surprised if it was more than > > > > > > > > > a half dozen pixels to compensate for the jitter in the cases > > > > > > > > > where the internal timing generator is mandatory due to > > > > fractional bytes. > > > > > > > > > > > > > > > > This is interesting and would proofs our assumption that the > > > > > > > > device don't have a FIFO :) > > > > > > > > > > > > > > > > Our assumptions (we don't have the datasheet/programming > > > > manual): > > > > > > > > - HDMI part is fetching 3 bytes per HDMI pixclk > > > > > > > > - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI > > > > and > > > > > > > > HDMI are in sync. So from bandwidth pov there are no > > > > differences > > > > > > > > between: > > > > > > > > - HDMI: 74.25 MHz * 24 Bit = 1782.0 MBit/s > > > > > > > > - DSI: 891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: > > > > 445.5 ) > > > > > > > > - DSI: 445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: > > > > > > > > 222.75) > > > > > > > > > > > > > > > > But the ratio is different and therefore the faster clocking > > > > option > > > > > > > > let something 'overflow'. > > > > > > > > > > > > > > I'll agree that all looks consistent. > > > > > > > > > > > > > > > Anyway, but all this means that Adam should configure the > > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this > > > > > > > > doesn't work either and now we are back on my initial statement > > > > > > > > -> the driver needs some attention. > > > > > > > > > > > > > > Things always need attention :-) > > > > > > > > > > > > ^^ > > > > > > > > > > > > > I suspect that it's the use of the timing generator that is the > > > > issue. > > > > > > > The programming guide does recommend using it for all modes, so > > > > > > > that would be a sensible first step. > > > > > > > > > > > > But I tested it without the timing-generator too. Can you or Adam > > > > > > verify the timing-generator diable logic? > > > > > > > > > > Sorry, running without the use of the timing generator is the issue. > > > > > It is mandatory in some modes, but supported in all modes. Always > > > > > using it should therefore avoid not using it in one of the mandatory > > > > > modes (the list looks a little arbitrary). I tested running various modes with the timing generator disable on an NXP kernel with functional video, and some of the video modes stopped operating or became blurry. With the generator on, it appeared to make the issues go away, so I think it should be left on. > > > > > > > > > > > > I will say that we had a number of issues getting this chip to do > > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead > > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite > > > > > > > some assistance from ADI. > > > > > > > > > > > > Even more interessting, what is your alternative to this chip? > > > > > > > > > > BCM2711 which supported dual HDMI natively. > > > > > Our investigation of ADV7535 was when trying to build what became > > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I > > > > > do have the prototype, the ADV was wired up weirdly with I2C so I > > > > > never really got it running with Linux. > > > > > > > > I think I have convinced myself that the DSIM is working good enough to > > > > match that of the NXP. > > > > > > > > I've gone through and made a list of the register differences between a > > > > working display using NXP's kernel and the non-working display. I've > > > > identified a small handful of registers on both the CEC bank of > > > > registers and main set of registers. > > > > > > > > I noticed that the working NXP version doesn't rescale the number of > > > > lanes based on the clock rate, and it stays fixed at 4 lanes. > > > > > > Does it mean theoretically rescale of lanes is not required?? > > > > On the custom kernel from NXP, I can sync at 720p at 4-lanes. > > Unfortunately, I haven't yet been able to replicate all the register > > settings between my working version at 720p and my non-working > > version, and I still have yet to sync at 720p using the mainline > > adv7535 driver. I am still wrokong on it. > > > > > At least 2 platforms can work with fixed 4 lanes@720p. > > Based on what I'm seeing for this NXP platform, it almost seems like > the DSI transmitter should make the determination on whether or not to > scale the number of lanes instead of having the ADV7373 do it. Since > their custom kernel is able to do 720p in 4-lane mode with this part, > it doesn't seem unreasonable to me. I did a bunch of comparisons between registers for both the ADV7535 and the DSIM, and it appears that the video information is somehow different between the working NXP kernel and non-working one. The two main differences are around the values of htotal hfp. Both the DSIM and the ADV7535 are using different values for htotal and the hfp between the kernels. I am wondering if there is a bug in the 5.19 driver which is fetching wrong info or somehow the data isn't being calculated properly because both the DSIM and the ADV timings match each other, but don't match the working kernel. 720p Working on NXP: [ 24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 -> hfp_wc = 78 [ 24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24 [ 24.681496] adv7511_dsi_config_timing_gen: htotal 1652 [ 24.691372] adv7511_dsi_config_timing_gen: hfp 112 720p Not working: [ 106.424404] samsung_dsim_set_display_mode: vfp = 5 [ 106.429216] samsung_dsim_set_display_mode: bfp = 20 [ 106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 -> hfp_wc = 77 [ 106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24 [ 106.456314] LCD size = 1280x720 [ 106.470115] adv7511_dsi_config_timing_gen: htotal = 1650 [ 106.480707] adv7511_dsi_config_timing_gen: hfp = 110 adam > > > > > > > and looks like few platforms have display stability issue working with 4 lanes@720p, > > > so, as a workaround they changed to 3 lanes based on clock rate to make it work. > > > > > > Can you please confirm, is my understanding correct? > > > > That is my understanding. > > > > > > > > Note: > > > On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs > > > different pll parameters to generate the dot clock to work. > > > > The NXP platform I am using also needs to regenerate the clock. From > > what I can tell, it looks like the clock calculation on my board > > appears correct for both > > > > > > Cheers, > > > Biju _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5BC3CC00140 for ; Fri, 5 Aug 2022 21:18:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 48BE5B53BF; Fri, 5 Aug 2022 21:13:27 +0000 (UTC) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6A144B918F for ; Fri, 5 Aug 2022 21:05:48 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id y13so6952122ejp.13 for ; Fri, 05 Aug 2022 14:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=7p80Yi4ha4MyJClpDNxOS+05Egu0byNIpa228CYGpOc=; b=nl/5LUuB2pkS9TXIbwBqUrVbyqH6HqLPe8nskNgTbKZ7IUjejMaBU0iGwYkKMSCf4q qVsVuTEFiLVvQ+zcTAqbCFH1CiyPWOo/ojJwEdx93vy9SzsQsvgzWBqAMxkI/BPbRD6u yl2FGnGba0cl7d+3gl2ZwJ4BrOchNvd6WIK9hueCd7LMT+DqK7qzr/eaqV8HGfWRbq+U Ut6Z5vkWx0S0qZFyRHqhK1nmQQmAXH5pjFeEp76hF5i4mIXOfPFBdgCKGsW9XmUpVSaU vX+8m+jNBerR/Lc1mUah98zptzz4A78xBg89DOZ7J3UArdGVKfb9Z38OO3dqcdqnq+s/ ZbwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=7p80Yi4ha4MyJClpDNxOS+05Egu0byNIpa228CYGpOc=; b=hVLqtWik0dDDkoRm5ID9HHRfGwk90yyVdJIUROZu3E8Eza1R5qAAFfyj8ObqBM965i nW1b2fbspb2dSmMePPG7HakJn3jTkevGiL9KnUzSjEW5oQNkiFj0bfLOdk99nWhwMJz+ VNa/f5S+69dozyChmYLxX9dYf3BQZnIb1qHRI5deUhTFVmqxcy3A6J251/Sfhgw8fiBg kwnDea9bqBGgeaQRF3ZAmUMsUwMKIBnLwc5QIic8ogC5wyl0V6OLUWD+AHgHRW2lS6Vp oVuxvS6N9ul3DcQNUVxau1LHrPBLnSEQ4CzxvlJ+WtHlzq6ySNDcOfEABy2UIdXRRIy0 nkeA== X-Gm-Message-State: ACgBeo2rQMgNBBFam5WisAfG3/JsuGFw9b4V/UW7Sxbx3EgTRJp5w4gQ DGyj7gOqd/yXw7EEX4iwlPbwe74WBY4Cv4DZMXk= X-Google-Smtp-Source: AA6agR5eVG41whRe1NHXF3sWbALmE2zoW/5IRkdU1cMcXQ1qZaXWCncLfqYPVfsr+qJYNgvMprmisZkYpUcQ95Ypo5E= X-Received: by 2002:a17:907:a428:b0:730:aee3:2da7 with SMTP id sg40-20020a170907a42800b00730aee32da7mr6208248ejc.613.1659733546601; Fri, 05 Aug 2022 14:05:46 -0700 (PDT) MIME-Version: 1.0 References: <20220802080820.jyf3tfpgcj3pvbtp@pengutronix.de> <20220803062024.vn7awasmifkp5xow@pengutronix.de> <20220804093829.42kdelp7u4r743nv@pengutronix.de> <20220804125152.idyzetjqkjzgbbm2@pengutronix.de> In-Reply-To: From: Adam Ford Date: Fri, 5 Aug 2022 16:05:35 -0500 Message-ID: Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors To: Biju Das Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , Jagan Teki , Jernej Skrabec , Pengutronix Kernel Team , Neil Armstrong , David Airlie , Robert Foss , Sascha Hauer , Dave Stevenson , Marco Felsch , dri-devel , Linux Kernel Mailing List , Jonas Karlman , Laurent Pinchart , Andrzej Hajda , "robert.chiras@nxp.com" , NXP Linux Team , "laurentiu.palcu@nxp.com" , Shawn Guo , arm-soc , Marek Szyprowski Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote: > > > > > > Hi Adam and all, > > > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > > > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson > > > > wrote: > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > Hi Marco > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > wrote: > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > 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. > > > > > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes > > > > > for pixel clock < 80000 via a mipi_dsi_detach and _attach. Quirky, but > > > > > probably the only way it can be achieved in the current framework. > > > > > > > > > > > To sync up: we have two problems: > > > > > > 1) The 720P mode with static DSI host configuration isn't working > > > > > > without hacks. > > > > > > 2) The DSI link frequency should changed as soon as required > > > > > > automatically. So we can provide all modes. > > > > > > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > > > > > > > > > If you change your link frequency, it may be worth trying a lower > > > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4 > > > > > lanes is again listed as mandatory for using the timing generator). > > Marco, > > Looking through the DSIM driver that NXP uses, it appears that they > have a few special cases where they intentionally manipulate the DSIM > under certain conditions: > > /* '1280x720@60Hz' mode with 2 data lanes > * requires special fine tuning for DPHY > * TIMING config according to the tests. > */ > > There is also a separate one for the 4-lane mode: > > /* workaround for CEA standard mode "1280x720@60" "1920x1080p24" > * display on 4 data lanes with Non-burst with sync > * pulse DSI mode, since use the standard horizontal > * timings cannot display correctly. And this code > * cannot be put into the dsim Bridge's mode_fixup, > * since the DSI device lane number change always > * happens after that. > */ > > And lastly, they address issues with 3-lane mode: > > /* TODO: DSIM 3 lanes has some display issue, so > * avoid 3 lanes enable, and force data lanes to > * be 2. > */ > > Since the ADV is trying to adjust the lanes to 3 when running at 720p, > it could be part of the reason you need to jump to 2-lane mode. > > > > > > > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as > > > > > > > one of the modes that is mandatory to use the timing generator > > > > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required. > > > > > > > I don't know why it's referencing the 1000/1001 pixel clock rates > > > > > > > and not the base one, as it's only a base clock change with the > > > > > > > same timing (74.176MHz clock instead of 74.25MHz). > > > > > > > > > > > > Interesting! I would like to know how the HDMI block gets fetched by > > > > > > the DSI block and how the timing-generator can influence this in > > > > > > good/bad way. So that we know what DSI settings (freq, lanes) are > > > > sufficient. > > > > > > > > > > > > > > > If you do program the manual DSI divider register to allow a > > > > > > > > > DSI pixel rate of 148.5MHz vs HDMI pixel rate of 74.25MHz, > > > > > > > > > you'd be relying on > > > > > > > > > > > > > > > > There is no such DSI pixel rate to be precise, we only have a > > > > > > > > DSI bit clock/rate. > > > > > > > > > > > > > > > > > the ADV753x having at least a half-line FIFO between DSI rx > > > > > > > > > and HDMI tx to compensate for the differing data rates. I see > > > > > > > > > no reference to such, and I'd be surprised if it was more than > > > > > > > > > a half dozen pixels to compensate for the jitter in the cases > > > > > > > > > where the internal timing generator is mandatory due to > > > > fractional bytes. > > > > > > > > > > > > > > > > This is interesting and would proofs our assumption that the > > > > > > > > device don't have a FIFO :) > > > > > > > > > > > > > > > > Our assumptions (we don't have the datasheet/programming > > > > manual): > > > > > > > > - HDMI part is fetching 3 bytes per HDMI pixclk > > > > > > > > - Ratio between dsi-clk and hdmi-pixelclk must be 3 so the DSI > > > > and > > > > > > > > HDMI are in sync. So from bandwidth pov there are no > > > > differences > > > > > > > > between: > > > > > > > > - HDMI: 74.25 MHz * 24 Bit = 1782.0 MBit/s > > > > > > > > - DSI: 891 MHz * 2 lanes = 1782.0 MBit/s (dsi-clock: > > > > 445.5 ) > > > > > > > > - DSI: 445.5 MHz * 4 lanes = 1782.0 MBit/s (dsi-clock: > > > > > > > > 222.75) > > > > > > > > > > > > > > > > But the ratio is different and therefore the faster clocking > > > > option > > > > > > > > let something 'overflow'. > > > > > > > > > > > > > > I'll agree that all looks consistent. > > > > > > > > > > > > > > > Anyway, but all this means that Adam should configure the > > > > > > > > burst-clock-rate to 445.5 and set the lanes to 4. But this > > > > > > > > doesn't work either and now we are back on my initial statement > > > > > > > > -> the driver needs some attention. > > > > > > > > > > > > > > Things always need attention :-) > > > > > > > > > > > > ^^ > > > > > > > > > > > > > I suspect that it's the use of the timing generator that is the > > > > issue. > > > > > > > The programming guide does recommend using it for all modes, so > > > > > > > that would be a sensible first step. > > > > > > > > > > > > But I tested it without the timing-generator too. Can you or Adam > > > > > > verify the timing-generator diable logic? > > > > > > > > > > Sorry, running without the use of the timing generator is the issue. > > > > > It is mandatory in some modes, but supported in all modes. Always > > > > > using it should therefore avoid not using it in one of the mandatory > > > > > modes (the list looks a little arbitrary). I tested running various modes with the timing generator disable on an NXP kernel with functional video, and some of the video modes stopped operating or became blurry. With the generator on, it appeared to make the issues go away, so I think it should be left on. > > > > > > > > > > > > I will say that we had a number of issues getting this chip to do > > > > > > > anything, and it generally seemed happier on 2 or 3 lanes instead > > > > > > > of 4. Suffice to say that we abandoned trying to use it, despite > > > > > > > some assistance from ADI. > > > > > > > > > > > > Even more interessting, what is your alternative to this chip? > > > > > > > > > > BCM2711 which supported dual HDMI natively. > > > > > Our investigation of ADV7535 was when trying to build what became > > > > > Pi400 using BCM2710/BCM2837 (only has a single HDMI output). Whilst I > > > > > do have the prototype, the ADV was wired up weirdly with I2C so I > > > > > never really got it running with Linux. > > > > > > > > I think I have convinced myself that the DSIM is working good enough to > > > > match that of the NXP. > > > > > > > > I've gone through and made a list of the register differences between a > > > > working display using NXP's kernel and the non-working display. I've > > > > identified a small handful of registers on both the CEC bank of > > > > registers and main set of registers. > > > > > > > > I noticed that the working NXP version doesn't rescale the number of > > > > lanes based on the clock rate, and it stays fixed at 4 lanes. > > > > > > Does it mean theoretically rescale of lanes is not required?? > > > > On the custom kernel from NXP, I can sync at 720p at 4-lanes. > > Unfortunately, I haven't yet been able to replicate all the register > > settings between my working version at 720p and my non-working > > version, and I still have yet to sync at 720p using the mainline > > adv7535 driver. I am still wrokong on it. > > > > > At least 2 platforms can work with fixed 4 lanes@720p. > > Based on what I'm seeing for this NXP platform, it almost seems like > the DSI transmitter should make the determination on whether or not to > scale the number of lanes instead of having the ADV7373 do it. Since > their custom kernel is able to do 720p in 4-lane mode with this part, > it doesn't seem unreasonable to me. I did a bunch of comparisons between registers for both the ADV7535 and the DSIM, and it appears that the video information is somehow different between the working NXP kernel and non-working one. The two main differences are around the values of htotal hfp. Both the DSIM and the ADV7535 are using different values for htotal and the hfp between the kernels. I am wondering if there is a bug in the 5.19 driver which is fetching wrong info or somehow the data isn't being calculated properly because both the DSIM and the ADV timings match each other, but don't match the working kernel. 720p Working on NXP: [ 24.657957] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 112 -> hfp_wc = 78 [ 24.665284] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24 [ 24.681496] adv7511_dsi_config_timing_gen: htotal 1652 [ 24.691372] adv7511_dsi_config_timing_gen: hfp 112 720p Not working: [ 106.424404] samsung_dsim_set_display_mode: vfp = 5 [ 106.429216] samsung_dsim_set_display_mode: bfp = 20 [ 106.441777] sec_mipi_dsim_set_main_mode: vmode->hfront_porch 110 -> hfp_wc = 77 [ 106.449221] sec_mipi_dsim_set_main_mode: vmode->hsync_len 40 -> hsa_wc = 24 [ 106.456314] LCD size = 1280x720 [ 106.470115] adv7511_dsi_config_timing_gen: htotal = 1650 [ 106.480707] adv7511_dsi_config_timing_gen: hfp = 110 adam > > > > > > > and looks like few platforms have display stability issue working with 4 lanes@720p, > > > so, as a workaround they changed to 3 lanes based on clock rate to make it work. > > > > > > Can you please confirm, is my understanding correct? > > > > That is my understanding. > > > > > > > > Note: > > > On Renesas RZ/G2L platform, 720p with 3 lanes will work, but it needs > > > different pll parameters to generate the dot clock to work. > > > > The NXP platform I am using also needs to regenerate the clock. From > > what I can tell, it looks like the clock calculation on my board > > appears correct for both > > > > > > Cheers, > > > Biju