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 59C5CC19F28 for ; Wed, 3 Aug 2022 11:02:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235569AbiHCLCy (ORCPT ); Wed, 3 Aug 2022 07:02:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230272AbiHCLCv (ORCPT ); Wed, 3 Aug 2022 07:02:51 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84CCDA45A for ; Wed, 3 Aug 2022 04:02:50 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id gb36so5221359ejc.10 for ; Wed, 03 Aug 2022 04:02:50 -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=zxgCuHXvqBGV53L1EzFqMcpK4LaucGFDh7Te55uTYfI=; b=F3Lf5AT5HNki4cKAvSdXFqMfIWzz1TfCcYy+1hPz1R6nHXiIut+qNKn60SlWPW+3/y YfjUtWaLxatamH3JPmWeS4hkuRABneECWZTVIISUgmeFl1BD50UQgrJvEv4Wgte7xfpx SSHhO4njWJJlcXEuwNIa0ktmNRm0Ej3K29Qqsrsvmh30h46DilKnagQCIQ0dEQnWyKGK 3WDo46XHPjL1aBI99Crh0mxrKCTdL4ZMwJ3bZdcLFhKnW9eyXm0j4s33TudMxh5Imy8M XRAKQIcjIqvdiWNNlVMx+1VkMIjEzxlsX27X9aJa2wbDtz2qkFiMO71vCZBQbjPWkinG fPYA== 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=zxgCuHXvqBGV53L1EzFqMcpK4LaucGFDh7Te55uTYfI=; b=xhdl2PK36l3333KyhL21CrlINHEX8tviO3Y084omxPKJKSp0q9eMIa1rRdBqwgAdG/ 3xe1+hnN8VdeVK2FCLTC6+dp+tW9zAx79mQaiP1+xFagjqDjZr0pZVEnEczrVVMS4jkf +w3y30TzhIe/Mkqr5NlSkH4aIT1z5BCH81eORrWtzffxRCb+wT8X+hf6LWL2GW0FfNOk 4h2HW2vbiNnSYgN4nDwi92wLQzfAIZ6yO8Kk09/8GrqiPE/TG7TdTgmQ8Awb/qBPcvRi FinrBpu+0rxw6AU4perIQ3dyCS/Ml+AXuDJbSt3AzrOy0lhWFTkIVHG3k/iw8KUjcTbL qdow== X-Gm-Message-State: ACgBeo2rnSSjW4boVcq1Fa/vhqI4qVuFJ2KKjuaepIKaTH0uVHqjFe1l v6hWOcYshtI858LbFlBT4eY4GRCsMiTWV6KyZSQ= X-Google-Smtp-Source: AA6agR7ObxEWtwATMauPJTbh0Azra7vBLI4e8TscLwSRwrNkywCyZlDAjLltwHNg7cP/LTzPSuwmoMfcWmPJhJ9oras= X-Received: by 2002:a17:907:a428:b0:730:aee3:2da7 with SMTP id sg40-20020a170907a42800b00730aee32da7mr2164462ejc.613.1659524568874; Wed, 03 Aug 2022 04:02:48 -0700 (PDT) MIME-Version: 1.0 References: <20220801225538.qtdb5zd66g6ipewz@pengutronix.de> <20220802080820.jyf3tfpgcj3pvbtp@pengutronix.de> <20220803062024.vn7awasmifkp5xow@pengutronix.de> In-Reply-To: <20220803062024.vn7awasmifkp5xow@pengutronix.de> From: Adam Ford Date: Wed, 3 Aug 2022 06:02:37 -0500 Message-ID: Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors To: Marco Felsch Cc: Fabio Estevam , Marek Vasut , Stefan Agner , Jernej Skrabec , Daniel Vetter , Jonas Karlman , David Airlie , dri-devel , Neil Armstrong , NXP Linux Team , Robert Foss , Linux Kernel Mailing List , Pengutronix Kernel Team , Laurent Pinchart , Andrzej Hajda , Marek Szyprowski , Shawn Guo , Sascha Hauer , arm-soc , Jagan Teki , robert.chiras@nxp.com, laurentiu.palcu@nxp.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 3, 2022 at 1:20 AM Marco Felsch wrote: > > On 22-08-02, Adam Ford wrote: > > ... > > > > I did some reading about the internal timing generator. It appears > > > that it's required when video formats use fractional bytes, and it's > > > preconfigured to run at 720p by default, but registers 28h through 37h > > > configure it for other video modes. > > > > I think there may still be some issues with the DSIM since some of the > > clock frequencies are set in the device tree. > > > > From what I can tell, the pixel rate is calculated based on the > > By pixel rate you mean the HDMI pixel rate from the ADV? If so then yes. > The ADV has an divider which is already configured by the driver but > meaningless since the driver is lacking of setting the "manual-divider" > bit within the same register. I was thinking about the pixel clock from the DSI to the ADV. I did see the manual-divider bit was missing. I tried enabling that bit, but it didn't appear to make much difference. > > > burst-clock-frequency and that generates a byte clock. For 891000000, > > the byte clock is 111375000. > > The burst-clock-frequency is the hs-clk and DDR. So the MIPI-DSI clock > is burst-clock-frequency/2 which is in your case: 891000000/2 = > 445500000. This clock is than divided by 3 within the ADV and you get > your 148500000 pixel clock. This divide by 3 is detected automatically > by the ADV due to the missing bit (see above). > > > Modetest timings for 1080p show: > > > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot > > #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 > > flags: nhsync, nvsync; type: driver > > > > > > When looking at modetest, there is a clock for 1080p which appears to be 148500. > > 111375000/148500 = 750. > > Please see above. > > > The rest of the entries in my table do not divide evenly. I don;t > > know if that explains the lack of display, but it's something to note. > > It seems to me that instead of fixing the > > samsung,burst-clock-frequency to 891000000, we should make the desired > > PLL related to the desired pixel clock so it divides evenly. > > Please see above. > > > Looking at NXP's kernel, I also noticed that their esc_prescaler is > > based on the byte clock divided by 20MHz. With some small code > > changes to get the PLL based on the desired pixel clock instead of > > hard-coded, I was able to set > > > > samsung,burst-clock-frequency = <1500000000>; > > This is not correct since the burst-clock-freq. specifies the hs-clock > for the data lanes (see above). But I don't think the clock should be fixed. I think it should vary as the resolution changes. From what I can tell, NXP's DSI code doesn't hard code this value, but it does appear to cap it at 1.5G. I did soom looking into the NXP frequency calculation and it is capable of adjusting resolutions to some extent and from what I can see the 891MHz clock is only set when 1080p. At 720p, thier kernel shows the output frequency at 445.5 MHz. The way the DSIM is currently configured, it's fixed at 891MHz, so I don't expect the output feeding the adv7535 to be correct for the different resolutions. > > > samsung,esc-clock-frequency = <20000000>; > > This is correct, we also use a esc-clock of 20MHz. > > > With these settings and the above mentioned code changes, 1080p still > > appears, however when attempting other modes, the display still fails > > to load. I also noticed that the phy ref clock is set to 27MHz > > instead of NXP's 12MHz. > > That's interesting, I didn't noticed that NXP uses 12 MHz as refclock > but I don't think that this is the problem. Since we have other > converter chips using the bridge driver and they work fine. I still > think that the main problem is within the ADV driver. Do the other converter chips work fine at different resolutions? > > > I attempted to play with that setting, but I couldn't get 1080p to > > work again, so I backed it out. > > > > Maybe I am headed in the wrong direction, but I'm going to examine the > > P/M/S calculation of the timing on NXP's kernel to see how the DSIM in > > this code compares. > > I think the pms values are fine. I compared the P/M/S values between this driver and NXP's and they calculate different values of PMS when running at 1080P. NXP @ 1080p: fout = 891000, fin = 12000, m = 297, p = 2, s = 1, best_delta = 0 This kernel @ 1080p: PLL freq 891000000, (p 3, m 99, s 0) at 720P, the NXP Kernel fout = 445500, fin = 12000, m = 297, p = 2, s = 2, best_delta = 0 (working) at 720P, this kernel: PLL freq 891000000, (p 3, m 99, s 0) hs_clk = 891000000, byte_clk = 111375000, esc_clk = 18562500 (not working) > > > If someone who understands the interactions between these different > > components has suggestions, I'm willing to run some experiments. > > 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. adam > > Regards, > Marco