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 3E95FC25B06 for ; Thu, 4 Aug 2022 14:52:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240073AbiHDOwR (ORCPT ); Thu, 4 Aug 2022 10:52:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240061AbiHDOwJ (ORCPT ); Thu, 4 Aug 2022 10:52:09 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FB5F2613B for ; Thu, 4 Aug 2022 07:52:07 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id gb36so11751711ejc.10 for ; Thu, 04 Aug 2022 07:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BWfvbI/fCQxffa07xrH5Bhn2ICjeR5HGQt2MGWBy+fg=; b=WzTrf9lbqKCko1Ohdl7g6gYcc1+ksnl0iyuqBbyzdeXMm3kBSFu/bf5X8iSScnV1X/ WCejVUwAXVtjzDQXUyrOUvLIH8by18+X98DTdZH2GXlm6S178Sd3QUaJ9cVbfr/eQIkb /jVRYJ2OR9h9YmhtibjX/Sd+txsGUFoAaKvzfZNQgkJsgDi9jJdjICHvTjCnvCAaKfrJ RjNZHm/zVBCnsHAmFSAFRuXmbbBBY98dNgMTdUqtO2CYfdgVC/vd0ChQK+QhuswXHD9r 0B8rXxJiRUBj8qkgxHrQfrJOTNJh6QlMAdtAP3AD9Slv+iW0QUPtrtvSahpRRrsD8AuU AOQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BWfvbI/fCQxffa07xrH5Bhn2ICjeR5HGQt2MGWBy+fg=; b=DBiBWEmiPawWd696bVJCETg/oUi+WQlDHAKtTGDNUwwD/Ju0233Dpz+IpAhkBhvIJS FmnKIxXfHDDMZw/Q8CX5DYYNPtR2duCgnOd6phhKm4djfPXY51q47QkZbk+N1+HOf2Qv 9A092Bc5PCI2WPY3K4UmmTK7VhOZ/JGhcW20rQnASOypdbGdqWpSFJBeXlRzRJ7fiXZH yzyD8F+/wTFjcNg2mY09+DQ8QK701Dadwlh23yWGx++L7ClyD1bLYLgn+JrEKAEPymIf FdqAZ61FlaqFV2itk3MVnbv0G3EZDQaHCSk4G8lM+TTgRE16UC60RbSX//oBbcDQEusJ Khvg== X-Gm-Message-State: ACgBeo0k3xwNuYOnQJ232rKURcUwPypEetLHkT4yt/muJcwf+uIw55LB U7/Vxg9070j0c4kv6h+lH5fiusXYexYk3k5CIvj1lw== X-Google-Smtp-Source: AA6agR6dicmwfDEC/wLJzQTmUC5hwNo5Ku3TMvN+XWyi0mIjTYltdiGX2XrBVVs+SBHlPOLwnMoNtu9g/OACV35QSwk= X-Received: by 2002:a17:907:c07:b0:730:b91b:2cab with SMTP id ga7-20020a1709070c0700b00730b91b2cabmr1762872ejc.294.1659624725670; Thu, 04 Aug 2022 07:52:05 -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: <20220804125152.idyzetjqkjzgbbm2@pengutronix.de> From: Dave Stevenson Date: Thu, 4 Aug 2022 15:51:49 +0100 Message-ID: Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors To: Marco Felsch Cc: Adam Ford , 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 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). > > 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 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. Dave 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 BAEC6C19F2A for ; Thu, 4 Aug 2022 14:52:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7C4D29A85A; Thu, 4 Aug 2022 14:52:36 +0000 (UTC) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by gabe.freedesktop.org (Postfix) with ESMTPS id A1D939A85D for ; Thu, 4 Aug 2022 14:52:07 +0000 (UTC) Received: by mail-ej1-x62b.google.com with SMTP id gk3so25164418ejb.8 for ; Thu, 04 Aug 2022 07:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BWfvbI/fCQxffa07xrH5Bhn2ICjeR5HGQt2MGWBy+fg=; b=WzTrf9lbqKCko1Ohdl7g6gYcc1+ksnl0iyuqBbyzdeXMm3kBSFu/bf5X8iSScnV1X/ WCejVUwAXVtjzDQXUyrOUvLIH8by18+X98DTdZH2GXlm6S178Sd3QUaJ9cVbfr/eQIkb /jVRYJ2OR9h9YmhtibjX/Sd+txsGUFoAaKvzfZNQgkJsgDi9jJdjICHvTjCnvCAaKfrJ RjNZHm/zVBCnsHAmFSAFRuXmbbBBY98dNgMTdUqtO2CYfdgVC/vd0ChQK+QhuswXHD9r 0B8rXxJiRUBj8qkgxHrQfrJOTNJh6QlMAdtAP3AD9Slv+iW0QUPtrtvSahpRRrsD8AuU AOQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BWfvbI/fCQxffa07xrH5Bhn2ICjeR5HGQt2MGWBy+fg=; b=B/gARACVIFvY5RRBGfOqfMX5V9pdkh4B3sTtAP0+3mXq16r6jv0bxaxPx3AM3cV6UG 1t896DVox1jF0lME+2/2ZO9EnCZIFqHc9dfSyzLo9TU0IbyYLXsNyBg6CH4Qdt+ZGXRd pZJJwQ4tTJr5YrqMfP0v1q0fMZDT4SwpILdBCwtjleqZnK/S11ivb55tpwqIZ++7hHFw cYz5F46yTvrcmboqe85crPU+wxgYycua23uN5ApozRqccYZt/YnlRFm+Hco+GhsxUyi4 w52PgR8dYwzsA7jGpVBQ7UjHMYC1A1Z27/C0ub+1Vw0cHxPB0gf6v9z8AB6MGd7I4A2V T6mw== X-Gm-Message-State: ACgBeo2NOqhOl2D69L6W1boKkghal+FWL7KslKvIbyRvDioRh1RfKcY9 FSIg6N/jZvoRuRMj7H94EKhN2vtYipCvYlfnf+CL/g== X-Google-Smtp-Source: AA6agR6dicmwfDEC/wLJzQTmUC5hwNo5Ku3TMvN+XWyi0mIjTYltdiGX2XrBVVs+SBHlPOLwnMoNtu9g/OACV35QSwk= X-Received: by 2002:a17:907:c07:b0:730:b91b:2cab with SMTP id ga7-20020a1709070c0700b00730b91b2cabmr1762872ejc.294.1659624725670; Thu, 04 Aug 2022 07:52:05 -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: <20220804125152.idyzetjqkjzgbbm2@pengutronix.de> From: Dave Stevenson Date: Thu, 4 Aug 2022 15:51:49 +0100 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: Marek Vasut , Jagan Teki , Jernej Skrabec , Pengutronix Kernel Team , Neil Armstrong , David Airlie , laurentiu.palcu@nxp.com, Sascha Hauer , Jonas Karlman , NXP Linux Team , dri-devel , Linux Kernel Mailing List , Laurent Pinchart , Andrzej Hajda , robert.chiras@nxp.com, Robert Foss , Adam Ford , Shawn Guo , arm-soc , Marek Szyprowski Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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). > > 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 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. Dave 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 EC494C19F2A for ; Thu, 4 Aug 2022 14:53:17 +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=FmAJ5ilGp2B3MgX0Vd1VElSr/LNIoOsXI5529t3ZfsA=; b=JVTSuFBWcvk2Zl pbyz43yeHxgqzVzQxfBwBIqGSsmfR115oAJl8UpzTpBmFvo6BrtOXZ2JFc9BCxeLUvtCL6+41Du9K rb/7QLhHDGxrmcpQFAK0I5blG/qvBVpmB+QmL24dMuiYKjQJumFqNuz+alknfA1tkEIXWuRZzJCNX F4J/+rI0B4Gv6M/kkh0maHu+GnSS5oUOwE947UqhlsNC07o1AOEMqh07r5Hj958nG4IGFO+G2Osr2 93fjGs/wGuZyD5c0PJpsUY8LcJE1neYf45YynSxTHc9v0G+X/nL5C97ljMzyQHTdCXrX5DgnzyT2E 9iXxUS8+SLyI6TrEeBbQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oJcCt-006tYV-Vf; Thu, 04 Aug 2022 14:52:16 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oJcCo-006tUs-Tl for linux-arm-kernel@lists.infradead.org; Thu, 04 Aug 2022 14:52:12 +0000 Received: by mail-ej1-x62f.google.com with SMTP id uj29so24201175ejc.0 for ; Thu, 04 Aug 2022 07:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BWfvbI/fCQxffa07xrH5Bhn2ICjeR5HGQt2MGWBy+fg=; b=WzTrf9lbqKCko1Ohdl7g6gYcc1+ksnl0iyuqBbyzdeXMm3kBSFu/bf5X8iSScnV1X/ WCejVUwAXVtjzDQXUyrOUvLIH8by18+X98DTdZH2GXlm6S178Sd3QUaJ9cVbfr/eQIkb /jVRYJ2OR9h9YmhtibjX/Sd+txsGUFoAaKvzfZNQgkJsgDi9jJdjICHvTjCnvCAaKfrJ RjNZHm/zVBCnsHAmFSAFRuXmbbBBY98dNgMTdUqtO2CYfdgVC/vd0ChQK+QhuswXHD9r 0B8rXxJiRUBj8qkgxHrQfrJOTNJh6QlMAdtAP3AD9Slv+iW0QUPtrtvSahpRRrsD8AuU AOQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BWfvbI/fCQxffa07xrH5Bhn2ICjeR5HGQt2MGWBy+fg=; b=l5NAM5l6rJm4+3s/zAR/qaes7FFt5DnsgdeswNduuCTjuXlpBK8ebRkmK/Ei1CCmYy LSDsnoAfWRyr/Axu7KYGRCJpWTGrD8qq8RB7+WLl+DXQC7oO/HK+webGJsYiqkbuTdGh 7Q6+XFjosHRV71+XyGxgtyKebl21TGxZ7lT/rIDx3RdFLtmgasS4azNPhwWKztb9UPM9 OemboKQNIgpMBs3CiGnYNVvN9uYTK4rcfyfmO4VIercQjseiPVXl6aK1EPhfd5EuXl0S 2hQ0XYqyD7oAZfO90M3aPoTESjQUnLcXrRIm8h3VJf/TXxMa7WQvDMoR1MsIYSyBuRmZ M5Hg== X-Gm-Message-State: ACgBeo1ioeP1UHzHwvFk4fdmHEYP1+RX1pOMmsChUYp3FVCmX9eVIPlZ fRvVdz/vzIWZ08iOxtouGn5AtAMMJpaMmq6KGEIIQQ== X-Google-Smtp-Source: AA6agR6dicmwfDEC/wLJzQTmUC5hwNo5Ku3TMvN+XWyi0mIjTYltdiGX2XrBVVs+SBHlPOLwnMoNtu9g/OACV35QSwk= X-Received: by 2002:a17:907:c07:b0:730:b91b:2cab with SMTP id ga7-20020a1709070c0700b00730b91b2cabmr1762872ejc.294.1659624725670; Thu, 04 Aug 2022 07:52:05 -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: <20220804125152.idyzetjqkjzgbbm2@pengutronix.de> From: Dave Stevenson Date: Thu, 4 Aug 2022 15:51:49 +0100 Message-ID: Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors To: Marco Felsch Cc: Adam Ford , 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-20220804_075211_069067_B71B4BF9 X-CRM114-Status: GOOD ( 65.02 ) 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 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). > > 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 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. Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel