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 58E48C19F2B for ; Wed, 3 Aug 2022 02:14:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233297AbiHCCOb (ORCPT ); Tue, 2 Aug 2022 22:14:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231560AbiHCCO3 (ORCPT ); Tue, 2 Aug 2022 22:14:29 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBDBB50733 for ; Tue, 2 Aug 2022 19:14:27 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id ss3so28927524ejc.11 for ; Tue, 02 Aug 2022 19:14:27 -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=5PfzgdkwKk8vgPVTM9VmmwC+o/EB6JpB4y6rlRNyThM=; b=WCDL7VdJKYamc04OZNM6Emi960roLI1Wg4lQOCL0k/GRrVSiXxLCr80L/Ph/kx8A6p 4eGb8Pr9BLTO0N5mIr8IRNe3C3QdpoG5mPykccOhVJxOXIpQBuCuFFsIg2qUtqFxV68C SYyxbuwZFgo5g+0TtO0f+UCDzwQX/QJMReXFaQirKgGcvwmINj0WIuDd4AQvXGMlUEmR BvuG7/BQa3OKK8m3Wm4XuesWDIF2w7qTRMoTnqiEnGIt99frrPl/f4QXsz2L5L/1bK0j 3vlR2t3JVUHmA2aISWQl9g+XofaUjZeNzB2pY3QqvOw5G9Wjs2HptoleurtoOm3b0ZCV yIBA== 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=5PfzgdkwKk8vgPVTM9VmmwC+o/EB6JpB4y6rlRNyThM=; b=hYunEWj5YEQg0gBjS/sjYl55z5GDh5Lk3496PTKv3hZpr/aWAYeOHgryKX+XldJq3M w2juX1VFAxvodpK+iELa3LOUpyjLWWC2EIpaUJr/Ck8ASMVLfCnE4vO1GxZP5K35jtUD GG56pu+xv87wuW9KZNWmfGvqZ3W2LiFaepnH6LuA0qbr7PW1eZgblc0c+9vTgyq+i044 ovfAg5eijweM1W0WfQ8f+KsSEBus3rGYj8B9lli/8przosMC33HQOuakzri/g/wSRWZJ AZ7aXhx/luglrr3v6fmZiBhDr56OB8MJEOp1Awa8zsUzEsJLCS/heKYH+CJmUoE0cB2U plgQ== X-Gm-Message-State: ACgBeo208BNur/lhV/6zxFzA42B3h3SH2uXZATQNpPR8umJcuhg3Oa1e k8EAuyRD9wGBNflOan/iz0FvS6fC2MIEM55Zu/Y= X-Google-Smtp-Source: AA6agR4LB+/dYGmRzWqiOBOhzTd/1zOEZINeD17iFmHGwgfAGxP61hT2stDKtnxOlK9eu6dglwUMUEXjaXegPG5nVMU= X-Received: by 2002:a17:907:a428:b0:730:aee3:2da7 with SMTP id sg40-20020a170907a42800b00730aee32da7mr828489ejc.613.1659492866192; Tue, 02 Aug 2022 19:14:26 -0700 (PDT) MIME-Version: 1.0 References: <20220801225538.qtdb5zd66g6ipewz@pengutronix.de> <20220802080820.jyf3tfpgcj3pvbtp@pengutronix.de> In-Reply-To: From: Adam Ford Date: Tue, 2 Aug 2022 21:14:15 -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 Tue, Aug 2, 2022 at 8:51 AM Adam Ford wrote: > > On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote: > > > > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > > > > > Hi Adam, Fabio, > > > > > > On 22-08-01, Adam Ford wrote: > > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote: > > > > > > > > > > > I managed to get my HDMI output working. I had the lanes set to 2 > > > > > > instead of 4. Once I switched to 4-lanes, the monitor came up in > > > > > > 1080p. I haven't yet been able to get other modes to work. > > > > > > > > > > Ok, good. On another thread, you mentioned that you were also trying > > > > > to get LVDS to work via SN65DSI83. > > > > > > > > > > Does LVDS work for you on this branch? > > > > > > > > I haven't tried with Marek's latest suggestion. In the other thread > > > > he mentioned a burst mode and setting the DSI speeds to higher > > > > frequencies, but the patch he had didn't look like it would apply > > > > cleanly, so I will need to dig into that a bit further. > > > > > > Can you provide me a link to this thread? > > > > Sure, > > > > https://www.spinics.net/lists/dri-devel/msg358301.html > > > > > > > > > Since my company doesn't really ship the LVDS displays with the kits, > > > > the HDMI is the default video, so I've been focusing on it. > > > > > > > > To answer Marco's question, I was able to revert "MLK-21958-13: > > > > drm/bridge: adv7511: Limit supported clocks" and still get a display > > > > at 1080p, but all the other resolutions I tried appear to come up > > > > blank. > > > > > > Cool so now you have the same state as we are. > > > > I have a couple patches applied to mine which mimic some of the stuff > > that NXP did. Since I have access to a programmer manual, i was able > > to confirm some of the 7535 specific stuff and the low-refresh rate > > changes in their kernel appear appropriate and I also created a second > > table of default settings for the 7535 and if the type is set > > properly, i'll use the newer table instead of the older one. If anyone > > wants any of these patches, I can certainly share them, but I am not > > certain they make any difference. > > > > There are a few other items in the programmer manual that I want to > > attempt to implement once I have a chance to further review the > > document. > > > > > > > > I think that the most important one is the blanking calc. Can you try to > > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check > > > if you can get a output still? Also something to try would be to disable > > > the internal timing generator by specifying > > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for > > 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 burst-clock-frequency and that generates a byte clock. For 891000000, the byte clock is 111375000. 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. 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. 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>; samsung,esc-clock-frequency = <20000000>; 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. 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. If someone who understands the interactions between these different components has suggestions, I'm willing to run some experiments. adam > > Are you thinking the imx8mm DSI generator would do it better? > > > > such frequencies you can check the hdmi clk-lane. I noticed that this is > > > sometimes wrong. > > > > I am doing this from my home office as a side project, so I don't have > > a scope, but I can try to revert the other patch and try to disable > > the internal timing generator when I get home tonight. I'll report my > > findings. > > > > > > > > Regards, > > > Marco > > > > > > > I didn't try every one. With that revert, more options come > > > > available, but 1440x900 and 800x600 were options I tried > > > > unsuccessfullyl. > > > > > > > > > > > adam > > > > 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 81844C19F28 for ; Wed, 3 Aug 2022 02:14:36 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A98AB8D162; Wed, 3 Aug 2022 02:14:34 +0000 (UTC) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by gabe.freedesktop.org (Postfix) with ESMTPS id E24428D162 for ; Wed, 3 Aug 2022 02:14:27 +0000 (UTC) Received: by mail-ej1-x62c.google.com with SMTP id gb36so3408787ejc.10 for ; Tue, 02 Aug 2022 19:14:27 -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=5PfzgdkwKk8vgPVTM9VmmwC+o/EB6JpB4y6rlRNyThM=; b=WCDL7VdJKYamc04OZNM6Emi960roLI1Wg4lQOCL0k/GRrVSiXxLCr80L/Ph/kx8A6p 4eGb8Pr9BLTO0N5mIr8IRNe3C3QdpoG5mPykccOhVJxOXIpQBuCuFFsIg2qUtqFxV68C SYyxbuwZFgo5g+0TtO0f+UCDzwQX/QJMReXFaQirKgGcvwmINj0WIuDd4AQvXGMlUEmR BvuG7/BQa3OKK8m3Wm4XuesWDIF2w7qTRMoTnqiEnGIt99frrPl/f4QXsz2L5L/1bK0j 3vlR2t3JVUHmA2aISWQl9g+XofaUjZeNzB2pY3QqvOw5G9Wjs2HptoleurtoOm3b0ZCV yIBA== 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=5PfzgdkwKk8vgPVTM9VmmwC+o/EB6JpB4y6rlRNyThM=; b=ss6w4EqWn+AntT5YoExU90Dka+A9YX8DS0WtOUorNTl1KIMNbxR8Onog8ykuxpKWJM irjG/Ix9GcMlnX/XeQjiaKVxFuCoboUxEVniabfBwm796uZr/ctm90gnpK/Df9G6Kzxl ruM2QLKYhwGxnUKut/dTOmn5W8+IssSVyVKjF9urUPbGlgM//i882c+S1eLE8J0Szbi6 B8lEqIC+FQL36A8X+JMibGVa93ZklHWhWZbe3YAfgISW7R7SR2cG/UUUE0HK+8rNnJfB AwlgPfrsUXP0/UtplNZwtEv08FxpkbbPjRtrmsMJ3Hrd7nEAk3sGhS9VpTHIiZSt3BhQ 0R5Q== X-Gm-Message-State: ACgBeo0+qyXX3pv5reFPqoozrZz6+n8Tmy4BmcGoyZT8q+x9q2oChOLY 1TG009VlM5kC3FbqNBKRO0L7vqV97n9zjhEHw+M= X-Google-Smtp-Source: AA6agR4LB+/dYGmRzWqiOBOhzTd/1zOEZINeD17iFmHGwgfAGxP61hT2stDKtnxOlK9eu6dglwUMUEXjaXegPG5nVMU= X-Received: by 2002:a17:907:a428:b0:730:aee3:2da7 with SMTP id sg40-20020a170907a42800b00730aee32da7mr828489ejc.613.1659492866192; Tue, 02 Aug 2022 19:14:26 -0700 (PDT) MIME-Version: 1.0 References: <20220801225538.qtdb5zd66g6ipewz@pengutronix.de> <20220802080820.jyf3tfpgcj3pvbtp@pengutronix.de> In-Reply-To: From: Adam Ford Date: Tue, 2 Aug 2022 21:14:15 -0500 Message-ID: Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors To: Marco Felsch 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: 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 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Aug 2, 2022 at 8:51 AM Adam Ford wrote: > > On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote: > > > > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > > > > > Hi Adam, Fabio, > > > > > > On 22-08-01, Adam Ford wrote: > > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote: > > > > > > > > > > > I managed to get my HDMI output working. I had the lanes set to 2 > > > > > > instead of 4. Once I switched to 4-lanes, the monitor came up in > > > > > > 1080p. I haven't yet been able to get other modes to work. > > > > > > > > > > Ok, good. On another thread, you mentioned that you were also trying > > > > > to get LVDS to work via SN65DSI83. > > > > > > > > > > Does LVDS work for you on this branch? > > > > > > > > I haven't tried with Marek's latest suggestion. In the other thread > > > > he mentioned a burst mode and setting the DSI speeds to higher > > > > frequencies, but the patch he had didn't look like it would apply > > > > cleanly, so I will need to dig into that a bit further. > > > > > > Can you provide me a link to this thread? > > > > Sure, > > > > https://www.spinics.net/lists/dri-devel/msg358301.html > > > > > > > > > Since my company doesn't really ship the LVDS displays with the kits, > > > > the HDMI is the default video, so I've been focusing on it. > > > > > > > > To answer Marco's question, I was able to revert "MLK-21958-13: > > > > drm/bridge: adv7511: Limit supported clocks" and still get a display > > > > at 1080p, but all the other resolutions I tried appear to come up > > > > blank. > > > > > > Cool so now you have the same state as we are. > > > > I have a couple patches applied to mine which mimic some of the stuff > > that NXP did. Since I have access to a programmer manual, i was able > > to confirm some of the 7535 specific stuff and the low-refresh rate > > changes in their kernel appear appropriate and I also created a second > > table of default settings for the 7535 and if the type is set > > properly, i'll use the newer table instead of the older one. If anyone > > wants any of these patches, I can certainly share them, but I am not > > certain they make any difference. > > > > There are a few other items in the programmer manual that I want to > > attempt to implement once I have a chance to further review the > > document. > > > > > > > > I think that the most important one is the blanking calc. Can you try to > > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check > > > if you can get a output still? Also something to try would be to disable > > > the internal timing generator by specifying > > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for > > 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 burst-clock-frequency and that generates a byte clock. For 891000000, the byte clock is 111375000. 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. 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. 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>; samsung,esc-clock-frequency = <20000000>; 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. 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. If someone who understands the interactions between these different components has suggestions, I'm willing to run some experiments. adam > > Are you thinking the imx8mm DSI generator would do it better? > > > > such frequencies you can check the hdmi clk-lane. I noticed that this is > > > sometimes wrong. > > > > I am doing this from my home office as a side project, so I don't have > > a scope, but I can try to revert the other patch and try to disable > > the internal timing generator when I get home tonight. I'll report my > > findings. > > > > > > > > Regards, > > > Marco > > > > > > > I didn't try every one. With that revert, more options come > > > > available, but 1440x900 and 800x600 were options I tried > > > > unsuccessfullyl. > > > > > > > > > > > adam > > > > 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 5266FC00140 for ; Wed, 3 Aug 2022 02:15:56 +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=MQFspE07n4Pufp9q9OFHhfXBT7zS5NwCrP/iQiLVlUI=; b=zSLtMXJoqQk5pY JHNcPh1GZsYLUf0fNvMDrbn7scoTDpLM3DzWyRHi3wBEWdOvKVt643IFudiMdFJARvJJhDvJUH59T 2q/NVPTGXG2uyITuf2ldvIHzvG3l864osi2aBgtuwEmo9t2Fd1FXgIVMwDsRB5ZCuerh3qmg6tG3w jbmRAPcAzW7narEOLl1cg98vuZdvtEvMMApw+3J2fGwchqRpnafjDK9ALpIJG8KWU8XT7+ZkMHJzC gO+LIMuGpW+vzMkNKMIPNegcZEseLt3zn3WbTQWnm52PLcTzY5qLfMaM5Xyk7Ag92TXc7UXWsMTPq ZPAeH+yxoybR/j5Mme4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oJ3u4-001YL8-UG; Wed, 03 Aug 2022 02:14:33 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oJ3u0-001YJC-S5 for linux-arm-kernel@lists.infradead.org; Wed, 03 Aug 2022 02:14:31 +0000 Received: by mail-ej1-x635.google.com with SMTP id a7so16018124ejp.2 for ; Tue, 02 Aug 2022 19:14:27 -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=5PfzgdkwKk8vgPVTM9VmmwC+o/EB6JpB4y6rlRNyThM=; b=WCDL7VdJKYamc04OZNM6Emi960roLI1Wg4lQOCL0k/GRrVSiXxLCr80L/Ph/kx8A6p 4eGb8Pr9BLTO0N5mIr8IRNe3C3QdpoG5mPykccOhVJxOXIpQBuCuFFsIg2qUtqFxV68C SYyxbuwZFgo5g+0TtO0f+UCDzwQX/QJMReXFaQirKgGcvwmINj0WIuDd4AQvXGMlUEmR BvuG7/BQa3OKK8m3Wm4XuesWDIF2w7qTRMoTnqiEnGIt99frrPl/f4QXsz2L5L/1bK0j 3vlR2t3JVUHmA2aISWQl9g+XofaUjZeNzB2pY3QqvOw5G9Wjs2HptoleurtoOm3b0ZCV yIBA== 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=5PfzgdkwKk8vgPVTM9VmmwC+o/EB6JpB4y6rlRNyThM=; b=CzuPSfRytEa+4N5AkjPOZBiOkmhAGm2egIHR6bjpGawKfcfLdN0VY6nxiNMsWOUBd2 KQHpvzAPXsBqipAKGQj34HaLGz+DHhlHr/blnY6aVY2am76vX2Qt2bti7Tcl6qmpgmAh vXzVSkYGE+di0yMBRSIDZDkPii6fxfL5BDjf+NcdEk+dxOzuToVBNIkbRVBfl48e2UiY k8HGunDQtQRTR+uqZe/pRfURLi6cL9sPrp3+oa8BUY4MJPa2T5tE3M0DMIA2QtnCdqgP MdE5L/Z3wgEhMjvS31IiQu4cAOH8dMd/61qRreHlOVod7UuQPhKHw9f5Hc66NuJE0ygw x60Q== X-Gm-Message-State: ACgBeo1d6nOrAIArm6o7FA25/WCoU3OWmUtiIHocVOKoMKdOCKQXeEBv 3PaRMBfikr1EMWT3XSjuVe0bR1HTEPd8GLQcGRw= X-Google-Smtp-Source: AA6agR4LB+/dYGmRzWqiOBOhzTd/1zOEZINeD17iFmHGwgfAGxP61hT2stDKtnxOlK9eu6dglwUMUEXjaXegPG5nVMU= X-Received: by 2002:a17:907:a428:b0:730:aee3:2da7 with SMTP id sg40-20020a170907a42800b00730aee32da7mr828489ejc.613.1659492866192; Tue, 02 Aug 2022 19:14:26 -0700 (PDT) MIME-Version: 1.0 References: <20220801225538.qtdb5zd66g6ipewz@pengutronix.de> <20220802080820.jyf3tfpgcj3pvbtp@pengutronix.de> In-Reply-To: From: Adam Ford Date: Tue, 2 Aug 2022 21:14:15 -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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220802_191428_962100_98CBC929 X-CRM114-Status: GOOD ( 58.41 ) 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 Tue, Aug 2, 2022 at 8:51 AM Adam Ford wrote: > > On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote: > > > > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > > > > > Hi Adam, Fabio, > > > > > > On 22-08-01, Adam Ford wrote: > > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote: > > > > > > > > > > > I managed to get my HDMI output working. I had the lanes set to 2 > > > > > > instead of 4. Once I switched to 4-lanes, the monitor came up in > > > > > > 1080p. I haven't yet been able to get other modes to work. > > > > > > > > > > Ok, good. On another thread, you mentioned that you were also trying > > > > > to get LVDS to work via SN65DSI83. > > > > > > > > > > Does LVDS work for you on this branch? > > > > > > > > I haven't tried with Marek's latest suggestion. In the other thread > > > > he mentioned a burst mode and setting the DSI speeds to higher > > > > frequencies, but the patch he had didn't look like it would apply > > > > cleanly, so I will need to dig into that a bit further. > > > > > > Can you provide me a link to this thread? > > > > Sure, > > > > https://www.spinics.net/lists/dri-devel/msg358301.html > > > > > > > > > Since my company doesn't really ship the LVDS displays with the kits, > > > > the HDMI is the default video, so I've been focusing on it. > > > > > > > > To answer Marco's question, I was able to revert "MLK-21958-13: > > > > drm/bridge: adv7511: Limit supported clocks" and still get a display > > > > at 1080p, but all the other resolutions I tried appear to come up > > > > blank. > > > > > > Cool so now you have the same state as we are. > > > > I have a couple patches applied to mine which mimic some of the stuff > > that NXP did. Since I have access to a programmer manual, i was able > > to confirm some of the 7535 specific stuff and the low-refresh rate > > changes in their kernel appear appropriate and I also created a second > > table of default settings for the 7535 and if the type is set > > properly, i'll use the newer table instead of the older one. If anyone > > wants any of these patches, I can certainly share them, but I am not > > certain they make any difference. > > > > There are a few other items in the programmer manual that I want to > > attempt to implement once I have a chance to further review the > > document. > > > > > > > > I think that the most important one is the blanking calc. Can you try to > > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check > > > if you can get a output still? Also something to try would be to disable > > > the internal timing generator by specifying > > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for > > 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 burst-clock-frequency and that generates a byte clock. For 891000000, the byte clock is 111375000. 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. 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. 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>; samsung,esc-clock-frequency = <20000000>; 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. 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. If someone who understands the interactions between these different components has suggestions, I'm willing to run some experiments. adam > > Are you thinking the imx8mm DSI generator would do it better? > > > > such frequencies you can check the hdmi clk-lane. I noticed that this is > > > sometimes wrong. > > > > I am doing this from my home office as a side project, so I don't have > > a scope, but I can try to revert the other patch and try to disable > > the internal timing generator when I get home tonight. I'll report my > > findings. > > > > > > > > Regards, > > > Marco > > > > > > > I didn't try every one. With that revert, more options come > > > > available, but 1440x900 and 800x600 were options I tried > > > > unsuccessfullyl. > > > > > > > > > > > adam > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel