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 13404C77B73 for ; Fri, 26 May 2023 12:52:57 +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:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/v8u45BYo7akW+Wrxe7fG0PAU+z5xrKZqTQmcQz5Qog=; b=DMhISoqYru3jaY clcYoYARmObLoBZa8Dr6sujs4G8bEEogoqdYWio6Wq/gn4GmU8aw5QsG5OMGUJ3Z1Nb7QB3ohgMHP 2BsisMCKLe8YzpYDHnbsUHnh4C35OeBjBK+0hrVxbbptnfb0QadUzJHrBTg5E5pcEMEXYmYhC9s7e a2kzJzsF4XKYHyOz05rnNn4NIkUjRaQ6lMoY9sT8EMyRlywrhScBkX2thYM413oHnG1H5R55m/+zd l8Gr+L8E//OblfjlBenWrPnEoT/61OF9FCI6uyEOrzwB7Yb+4C/1E+YEG6/7x3NWXnrqDtDpgTLlH Paf47spOHHcttTXdJvPQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q2Wvj-002XWn-1U; Fri, 26 May 2023 12:52:27 +0000 Received: from mx1.tq-group.com ([93.104.207.81]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q2Wvg-002XVT-1K for linux-arm-kernel@lists.infradead.org; Fri, 26 May 2023 12:52:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1685105544; x=1716641544; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=P56jRYx8x4wiLyblEJCYsDvHn8dkjs3K/b4UWx2IjD8=; b=q+oHCg1Aq6aFuXJrs88uKh3il/oID1SbW2JyBGHRN6SRzFsNSa06KG1X cJnIBt7oUL6x5REccnhBRi+9sg0WC36EBVM7Ia/SIDfaDPFZPM8actx3G /jsEmB0GGSm39MX3r5POpx9mE4z7+yKO9kMJp1zczjL8BM57+o+Ersjff 3nSSUIYeKBKV0y5UPftexhxABPKuTYQcy4HCIoF5sPbTHr/6LczCZaIm6 cCjsmHWMqPTizMABNKTvAwyglavVfhT8ZYBZbuJMdk2tJMUsKoYC0mM3b 8+4dZd6oC+gedC3OxBTLTLUtDfhXEJzBiPXPrQZ0twI/ud/88WZgNwYE0 w==; X-IronPort-AV: E=Sophos;i="6.00,194,1681164000"; d="scan'208";a="31128837" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 26 May 2023 14:52:21 +0200 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Fri, 26 May 2023 14:52:21 +0200 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Fri, 26 May 2023 14:52:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1685105541; x=1716641541; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=P56jRYx8x4wiLyblEJCYsDvHn8dkjs3K/b4UWx2IjD8=; b=XtHxJgaFzNgqe1Zu1AOsjHGfuE9A/6NgT7djD9nkyi6A/p2UW+vftRxa YNRyuB0L3CeqCOJUn2P2JTc9qAjURkzfP/VvqZrd0ZdYXoPM4jWYPDCdv yvpR2mlrZg1OZe5DRIVLbVWopBJE++DXpiDNHTI7ZIhFCvV9oTPPqea5/ zrzuTa8Q+UQ9ltnY1wd8RuibKb6ycOyqMtxqPmuhOJnOONNr+Ejan8pN8 ftTatV16rGYHkXVLfBA9sXEfxZfVzVGABmmAYuaMk9OnWCq1Y8Y0XURD2 /zUIegsFxdWTsccLF2ixZhwg1NoKej8iQa6CxEWbnTRc5mkz2rWFRsP/G Q==; X-IronPort-AV: E=Sophos;i="6.00,194,1681164000"; d="scan'208";a="31128836" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 26 May 2023 14:52:21 +0200 Received: from steina-w.localnet (unknown [10.123.53.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by vtuxmail01.tq-net.de (Postfix) with ESMTPSA id 64188280082; Fri, 26 May 2023 14:52:21 +0200 (CEST) From: Alexander Stein To: Marek Vasut Cc: linux-arm-kernel@lists.infradead.org, Conor Dooley , Fabio Estevam , Krzysztof Kozlowski , NXP Linux Team , Pengutronix Kernel Team , Rob Herring , Sascha Hauer , Shawn Guo , devicetree@vger.kernel.org Subject: Re: [PATCH] arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM Date: Fri, 26 May 2023 14:52:21 +0200 Message-ID: <7530294.EvYhyI6sBW@steina-w> Organization: TQ-Systems GmbH In-Reply-To: <75c45018-fae3-aa9d-db5d-7d378f69b53c@denx.de> References: <20230515162424.67597-1-marex@denx.de> <1953702.usQuhbGJ8B@steina-w> <75c45018-fae3-aa9d-db5d-7d378f69b53c@denx.de> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230526_055224_833967_CD5A401E X-CRM114-Status: GOOD ( 22.46 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Marek, Am Mittwoch, 24. Mai 2023, 12:37:50 CEST schrieb Marek Vasut: > On 5/24/23 12:24, Alexander Stein wrote: > = > Hi, > = > >>> Looking at the AUX_CH+/- signals, I can see the native aux request and > >>> the > >>> (presumable) correct answer (DP_DPCD_REV register) from the display. = But > >>> for some reason the bridge runs into a aux timeout. > >>> I can see in the DP0_AUXSTATUS register the bus gets busy (0x1) after > >>> starting transfer. But after the tc_aux_wait_busy() call DP0_AUXSTATUS > >>> his indicating a timeout and sync error (0x310002). > >>> When changing the "Aux Bit Period Calculator Threshold" to 5 (register > >>> AUXCFG1), the sync error is gone, but the timeout still happens. > >>> = > >>> The frequency used from the display is ~1MHz, which should be okay. So > >>> on > >>> the electrical side all seems okay, but the native aux transfer don't > >>> work. > >> = > >> I recall DPCD read timeouts, but those were usually triggered by either > >> bad clock or wiring problems (the devkit wiring I used was horrible at > >> the beginning) from what I can recall. > > = > > bad clock in the sense of badly configured or bad xtal hardware? > = > As in, the xtal clock drives the internal PLLs and if those are > misconfigured for whatever reason, the chip can misbehave. You might > want to double-check the clock routing chapter in the toshiba bridge > datasheet and matching registers. > = > Have you tried forcing the chip into 1.62G (instead of 2.7G) operation > and into 1-lane DP instead of 2-lane DP mode ? Does that make any > difference ? The initial AUX problem is unrelated to DP link. I had problems way before = 2.7G or 2-lane DP comes into play. The problem in aux channel was caused by = bad clock input :( and the DSI host not putting all DSI lines into LP-11. For some reason apparently nobody had to do these kind of changes on = samsung_dsim. I had to enable all DSI lines (incl. clock) on dsim for the = bridge to properly use the AUX channel. With that fixed, DPCD read is successfull and DP link training seems okay, = as = I can enable the test pattern on the bridge. But displaying regular DSI stream is not working. I see the DSI error count= er = continuously increasing in the DSIERRCNT register (0x300). Forcing 1-lane DP or 1.62G operation reduces the possible resolution but = displaying does still not work. Best regards Alexander -- = TQ-Systems GmbH | M=FChlstra=DFe 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht M=FCnchen, HRB 105018 Gesch=E4ftsf=FChrer: Detlef Schneider, R=FCdiger Stahl, Stefan Schneider http://www.tq-group.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel