Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp296840imn; Thu, 4 Aug 2022 06:27:59 -0700 (PDT) X-Google-Smtp-Source: AA6agR5XKVupvNxQBeTbEro0jVBkzC3Xpt72O5WEYHerIBYiMSK6D/va3jbj8NhyqV0I13+8KKA3 X-Received: by 2002:a17:90a:988:b0:1f2:3dff:f1dd with SMTP id 8-20020a17090a098800b001f23dfff1ddmr2230664pjo.150.1659619679260; Thu, 04 Aug 2022 06:27:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659619679; cv=none; d=google.com; s=arc-20160816; b=siwRjYqFN+oSC89EJou4lGrrZJaowB9M2qcCDIjYEot3e4KPKOW3ZYHEYtsREv4RlK y2JfH64Xa3rjz+Xu3vyEkmnBwCYYnHPdJ+IiaSgM65gur42kJ7PWPfpFyEjsFfMlz5Tq cjZ+OcA6ofXak2qzY9+hgxbKxYyqIRrfVC62QY1bayKhloLadGMpzwISCDJNdc9FMhVq XA4woNBR9wgqfNU1etUlFPzU/bTz4FnE+4ezEzM/rP2EKZzuD1pKTfAGH/NZXcZuogMh Ak6y0JbnCj1gCCMUJmpJd2hWd0sDt30xNSbVGbUDbFfQaVBlaBAVkK7p+Pxnk4UBFZok iyog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=uyhoTMqk8jwgGe/oM+RH7/VugC3QJg7Qxkw3ZVK2zxk=; b=pvQertUOtg5nsUniAdB28CGmaPnlX5JC8eRtmdkiRP0yBUqz+SVoUEptV6hxid2iHA cZiSCTmdhuKQLXVjQZRctCBA2x0A78cnNDjNUAGGfNdiIZbCnVGDvRM7EZkWX70M2KFa 8PohOaYjs/bMAwqTZYRa1wALEaMYMMLY1JdiATZeiwg0qFFFWAMVrku3ynOUUuq2S0i5 0gB3TsYUkb0XwwsxXXsWSBtRVd+c8zAkF2EobhbNzwWA1b8wKq7TEuFXvuePd4FtEvbp iAqZ097LLMSQfYLsW/StQrBxx1IMnZO7vEqgc8Ilv36gRGi7b33vrSywd/YYEoKjTWRv 2kWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b67-20020a621b46000000b005251a2f06bbsi900034pfb.59.2022.08.04.06.27.44; Thu, 04 Aug 2022 06:27:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239511AbiHDNRR (ORCPT + 99 others); Thu, 4 Aug 2022 09:17:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231807AbiHDNRP (ORCPT ); Thu, 4 Aug 2022 09:17:15 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E7CC1D329 for ; Thu, 4 Aug 2022 06:17:13 -0700 (PDT) Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oJaii-0005to-S6; Thu, 04 Aug 2022 15:17:00 +0200 Received: from mfe by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1oJaig-0003Yp-IU; Thu, 04 Aug 2022 15:16:58 +0200 Date: Thu, 4 Aug 2022 15:16:58 +0200 From: Marco Felsch To: Dave Stevenson 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 Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors Message-ID: <20220804131658.7iynxxvajqjtgh5k@pengutronix.de> References: <20220803062024.vn7awasmifkp5xow@pengutronix.de> <20220804102757.pc7hljonea43ytwg@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: mfe@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dave, On 22-08-04, Dave Stevenson wrote: > Hi Marco > > On Thu, 4 Aug 2022 at 11:28, Marco Felsch wrote: > > > > On 22-08-03, Dave Stevenson wrote: > > > On Wed, 3 Aug 2022 at 13:31, Adam Ford wrote: > > > > ... > > > > > > Mine also states the DSI source needs to provide correct video timing > > > > with start and stop sync packets. > > > > > > > > If I remember correctly, it seemed like Marek V wanted the hard coded > > > > samsung,burst-clock-frequency to go away so the clock frequency could > > > > be set dynamically. > > > > > > I've never worked with Exynos or imx8, but my view would be that > > > samsung,burst-clock-frequency should only be used if > > > MIPI_DSI_MODE_VIDEO_BURST is set in the mode_flags (it isn't for > > > adv7533/5). > > > > Some notes on that. The samsung,burst-clock-frequency is the > > hs-bit-clock-rate which is twice the dsi-clock-rate. This has nothing to > > do with the MIPI_DSI_MODE_VIDEO_BURST. > > > > > Without that flag the DSI link frequency should be running at the rate > > > defined by the mode clock, number of lanes, bpp, etc. > > > > IMHO the DSI link have only to guarantee the bandwidth is sufficient for > > the mode. > > DSI spec 8.11.3 Non-Burst Mode with Sync Events > "This mode is a simplification of the format described in Section > 8.11.2 (Non-Burst Mode with Sync Pulses) > ... > Pixels are transmitted at the same rate as they would in a > corresponding parallel display interface such as DPI-2." > > If you are running the DSI clock at anything other than that rate, > then AIUI you are in a burst mode (although you may choose not to drop > into LP mode). Yes, that makes sense to me. The bandwidth on the DSI side should match the one required on the other side (HDMI). Apart the fact that the ADV is working in mode 8.11.2 (Non-Burst Mode with Sync Pulses). > (One of my pet peeves that there is no documentation as to exactly > what MIPI_DSI_MODE_VIDEO_BURST is meant to mean. Seeing as in the DSI > spec all modes of 8.11 say that the host can drop to LP during > blanking if time allows, it surely has to be the time compression > element of 8.11.4 Burst Mode). Hm.. I don't have the DSI spec either but I thought that BURST mode allows the host to send the data as fast as possible and enter LP afterwards. > > > From the DSI spec (v 1.1 section 8.11.1): > > > "Non-Burst Mode with Sync Pulses – enables the peripheral to > > > accurately reconstruct original video timing, including sync pulse > > > widths." > > > "RGB pixel packets are time-compressed, leaving more time during a > > > scan line for LP mode (saving power) or for multiplexing other > > > transmissions onto the DSI link." > > > How can the peripheral reconstruct the video timing off a quirky link frequency? > > > > If the ADV couldn't reconstruct the sync signals, then we should not get > > any mode working but we get the 1080P mode working. > > > > > Unless the Exynos DSIM_CONFIG_REG register bit DSIM_BURST_MODE [1] > > > reconfigures the clock setup of the DSI block, then I don't see how > > > the Exynos driver can follow the DSI spec in that regard. > > > > Why do you think that the Exynos driver isn't following the spec? We > > configure the host into video mode with sync signals which is working > > for the 1080P mode. > > 1080p is working with samsung,burst-clock-frequency setting? Yes. > As I say, I've not worked with this IP, I'm only looking at it from > the outside having spent far too much time recently on the Pi DSI > interface. Good to know :) > exynos_drm_dsi.c seems to be doing a lot of PLL computation around > burst-clock-frequency, and nothing with the pixel clock rate. Yes currently there is just this setting for setting the PLL freq. but as you said for the "Non-Burst Mode with Sync Pulses" we need to reconfigure it according the required bandwidth or the dsi-device tells us about which dsi-link settings should be applied. > Without knowledge of what that DSIM_BURST_MODE bit in DSIM_CONFIG_REG > actually does in the hardware, I can only make guesses. 8<---------------------------------------------- Selects Burst mode in Video mode In Non-burst mode, RGB data area is filled with RGB data and Null packets, according to input bandwidth of RGB interface. In Burst mode, RGB data area is filled with RGB data only. 0 = Non-burst mode 1 = Burst mode 8<---------------------------------------------- According the current implementation we are in Non-burst mode. Regards, Marco > Perhaps it does ditch the burst clock and switch the bit clock to be > derived from the pixel clock of the upstream block, but that seems > unlikely. > > Dave >