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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31700C47420 for ; Thu, 1 Oct 2020 08:54:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BFAE1208B6 for ; Thu, 1 Oct 2020 08:54:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731641AbgJAIyM (ORCPT ); Thu, 1 Oct 2020 04:54:12 -0400 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:60579 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730378AbgJAIyI (ORCPT ); Thu, 1 Oct 2020 04:54:08 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 8589B580289; Thu, 1 Oct 2020 04:54:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 01 Oct 2020 04:54:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=aCuInhZvme0gvNR2gwI/zQvtYmr lJy91lYSNBnXMZcY=; b=Ss8leWBrTndXP2dNlMLxQ8EvPcUa3y0saYFq9O9y8hJ 7w/SSZ+E6/4u5srBu7bP4XKLdGI9ZmP4HalWrsHQ7/dHjAzCcAst0wAJqme7s9nP 9jIzqUeP1xJhC5fHhGQ7Q8ulClZZ6gtWOshTLPUascdSQqUpvIPcjnCr+iILpBVZ etR1Tig+hywUufMsgebRKB3WzwV9LAc3SQMruPwgxqjWlkXU/pZ17Pc/cxS3FJVe GUquXl82pjekK+kh/qbbdqUu6MjfI5wDSHSMQCdbabmqiJCgqUIM+Gxm6C9VO2Is kiR90qIcB0Urfv00mZ2SE2mz/SqXoiTiegwtfW0PrTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=aCuInh Zvme0gvNR2gwI/zQvtYmrlJy91lYSNBnXMZcY=; b=grEj/yD/j2hIrzAecibb4R 8NFSVpkyVwITqSLHhnxJnNMt29Bc48Sbs0eo91xQDCHk38Vmq/hFgQlTUiR3EbQW 6cHpULy60f7ZfzU/7IiRBgi6P6we6mP4w4KKkKSkJS/y1NPvh4T/hepE3YvvL0cf n9J4lrwrpiKVIODYztie0mbZrBN1VtYsRh1IgciYRvdUXlbvE6Em6vsnwpR47afR vIm3uwEgJsWXa9ovQvA2XynCeV0MKJMWWjWtc+eZZi7jLzBSU5XlyeeTBI+8pWdi HiqdXtjIUb96zvlCDGwPNSUs2iugSEWWUxIhNeO6PxalNGSbTnTT5RJoPc9v/suw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeggddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpedtleegieefhfeflefgjedtueeuudeljeetgeeggeekjedulefhuddvveeifefg leenucffohhmrghinheprhgrshhpsggvrhhrhihpihdrohhrghenucfkphepledtrdekle drieekrdejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A3CA3280059; Thu, 1 Oct 2020 04:54:04 -0400 (EDT) Date: Thu, 1 Oct 2020 10:54:02 +0200 From: Maxime Ripard To: Stefan Wahren Cc: Nathan Chancellor , Nicolas Saenz Julienne , Eric Anholt , Tim Gover , Dave Stevenson , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Hoegeun Kwon , Chanwoo Choi , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, Phil Elwell , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline Message-ID: <20201001085402.t6mzzwzplviunhoc@gilmour.lan> References: <20200929221526.GA1370981@ubuntu-m3-large-x86> <20200930140758.gummt3umouva3wyu@gilmour.lan> <20200930163823.GA237050@ubuntu-m3-large-x86> <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jq7qpluuzzoo6pw4" Content-Disposition: inline In-Reply-To: <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --jq7qpluuzzoo6pw4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote: > Hi Stefan, >=20 > On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote: > > Am 30.09.20 um 18:38 schrieb Nathan Chancellor: > > > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote: > > >> Hi Nathan, > > >> > > >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote: > > >>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote: > > >>>> Now that all the drivers have been adjusted for it, let's bring in= the > > >>>> necessary device tree changes. > > >>>> > > >>>> The VEC and PV3 are left out for now, since it will require a more= specific > > >>>> clock setup. > > >>>> > > >>>> Reviewed-by: Dave Stevenson > > >>>> Tested-by: Chanwoo Choi > > >>>> Tested-by: Hoegeun Kwon > > >>>> Tested-by: Stefan Wahren > > >>>> Signed-off-by: Maxime Ripard > > >>> Apologies if this has already been reported or have a solution but = this > > >>> patch (and presumably series) breaks output to the serial console a= fter > > >>> a certain point during init. On Raspbian, I see systemd startup mes= sages > > >>> then the output just turns into complete garbage. It looks like this > > >>> patch is merged first in linux-next, which is why my bisect fell on= the > > >>> DRM merge. I am happy to provide whatever information could be help= ful > > >>> for debugging this. I am on the latest version of the firmware > > >>> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241). > > >> Unfortunately, the miniUART is in the same clock tree than the core > > >> clock and will thus have those kind of issues when the core clock is > > >> changed (which is also something that one should expect when using t= he > > >> DRM or other drivers). > > >> > > >> The only real workaround there would be to switch to one of the PL011 > > >> UARTs. I guess we can also somehow make the UART react to the core c= lock > > >> frequency changes, but that's going to require some effort > > >> > > >> Maxime > > > Ack, thank you for the reply! There does not really seem to be a whole > > > ton of documentation around using one of the other PL011 UARTs so for > > > now, I will just revert this commit locally. > >=20 > > there was a patch series & discussion about this topic, but we finally > > didn't find a rock solid solution. > >=20 > > You can have a look at "[RFC 5/5] serial: 8250: bcm2835aux: add notifier > > to follow clock changes" from 3.4.2019 on linux-rpi-kernel. >=20 > I couldn't find that discussion on the archive, but based on the title I > guess there's some patches that have been merged this cycle for the 8250 > driver to do just that (868f3ee6e452 ("serial: 8250: Add 8250 port clock > update method") and cc816969d7b5 ("serial: 8250_dw: Fix common clocks > usage race condition")). >=20 > However, I'm not entirely sure the clock notifier works in our case with > the firmware / MMIO clocks duality I was a bit intrigued by this, so I looked into it, and it seems that it's worth that it used to be. The core clock is supposed to be running at 500 Mhz in most cases, and that's what we're setting so it shouldn't cause any pratical issue. However, it looks like on my board now the firmware reports that the core clock is running at either 311MHz or 233MHz with hdmi_enable_4k60 (which seems odd?) and that contradicts the documentation here: https://www.raspberrypi.org/documentation/configuration/config-txt/overcloc= king.md Linux then comes in, changes the frequency to 500MHz and breaks the UART. So either the doc is wrong, or the clock driver is. vcgencmd measure_clock core reports that it's indeed 233Mhz and I'm running a year-old firmware (built on the 2019-11-29), so I'd be inclined to think that the doc is wrong here or we're misinterpreting something. Dave, Tim, any idea? Thanks! Maxime --jq7qpluuzzoo6pw4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX3WZKgAKCRDj7w1vZxhR xfXhAQDFSw1QCBRSnfLzXomPVG2hE9XEQuCVtTqq9KDlhYul7QEAyzFgfN7GAZQK DDQsA+8Ty05gotg13ZSiA3io2xi10wI= =fxeW -----END PGP SIGNATURE----- --jq7qpluuzzoo6pw4-- 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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C33DC4727C for ; Thu, 1 Oct 2020 08:55:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A7553207F7 for ; Thu, 1 Oct 2020 08:55:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VYGGb/yG"; dkim=temperror (0-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="Ss8leWBr"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="grEj/yD/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7553207F7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=E/f6hiu0p2bxDYQ+/Dz6MdjjpX17Kajm9Dq0rEF1fww=; b=VYGGb/yG4FWHBEI8NM61JLFI2 ahhMYP1Z27Ac7QWUUGM1drVwoS9oaesSGpoCkOm4zkJod//EVnN85w2+9Eh3uqaNaEWsX3CO3iWg8 gVAvTzSqZNLwuTa9TNFTSYfoDdO+p+EHcR7olpLdPEBGfqVPdMSWqjUTO/s15+6rRUFsW9c/4i+zK Wm11lVfRlefCugT/28fjkMWH5VHbklBA0suYcDbGsfdNlka2WzZN3JjTx5zaohE3hrGUEmGzjA/NP L86khsKHyAOlZibHiLlJL1z8NdrZ81R+5mq8Mb4TrYgR6om/SZZerh8apPYbWLwFV45Gy1XsGn69G XX/VxOOSw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNuLt-0006tE-G6; Thu, 01 Oct 2020 08:54:13 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNuLq-0006qt-PN; Thu, 01 Oct 2020 08:54:12 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 8589B580289; Thu, 1 Oct 2020 04:54:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 01 Oct 2020 04:54:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=aCuInhZvme0gvNR2gwI/zQvtYmr lJy91lYSNBnXMZcY=; b=Ss8leWBrTndXP2dNlMLxQ8EvPcUa3y0saYFq9O9y8hJ 7w/SSZ+E6/4u5srBu7bP4XKLdGI9ZmP4HalWrsHQ7/dHjAzCcAst0wAJqme7s9nP 9jIzqUeP1xJhC5fHhGQ7Q8ulClZZ6gtWOshTLPUascdSQqUpvIPcjnCr+iILpBVZ etR1Tig+hywUufMsgebRKB3WzwV9LAc3SQMruPwgxqjWlkXU/pZ17Pc/cxS3FJVe GUquXl82pjekK+kh/qbbdqUu6MjfI5wDSHSMQCdbabmqiJCgqUIM+Gxm6C9VO2Is kiR90qIcB0Urfv00mZ2SE2mz/SqXoiTiegwtfW0PrTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=aCuInh Zvme0gvNR2gwI/zQvtYmrlJy91lYSNBnXMZcY=; b=grEj/yD/j2hIrzAecibb4R 8NFSVpkyVwITqSLHhnxJnNMt29Bc48Sbs0eo91xQDCHk38Vmq/hFgQlTUiR3EbQW 6cHpULy60f7ZfzU/7IiRBgi6P6we6mP4w4KKkKSkJS/y1NPvh4T/hepE3YvvL0cf n9J4lrwrpiKVIODYztie0mbZrBN1VtYsRh1IgciYRvdUXlbvE6Em6vsnwpR47afR vIm3uwEgJsWXa9ovQvA2XynCeV0MKJMWWjWtc+eZZi7jLzBSU5XlyeeTBI+8pWdi HiqdXtjIUb96zvlCDGwPNSUs2iugSEWWUxIhNeO6PxalNGSbTnTT5RJoPc9v/suw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeggddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpedtleegieefhfeflefgjedtueeuudeljeetgeeggeekjedulefhuddvveeifefg leenucffohhmrghinheprhgrshhpsggvrhhrhihpihdrohhrghenucfkphepledtrdekle drieekrdejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A3CA3280059; Thu, 1 Oct 2020 04:54:04 -0400 (EDT) Date: Thu, 1 Oct 2020 10:54:02 +0200 From: Maxime Ripard To: Stefan Wahren Subject: Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline Message-ID: <20201001085402.t6mzzwzplviunhoc@gilmour.lan> References: <20200929221526.GA1370981@ubuntu-m3-large-x86> <20200930140758.gummt3umouva3wyu@gilmour.lan> <20200930163823.GA237050@ubuntu-m3-large-x86> <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> MIME-Version: 1.0 In-Reply-To: <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201001_045410_926702_F154DCD1 X-CRM114-Status: GOOD ( 40.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org, Chanwoo Choi , Tim Gover , Dave Stevenson , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Phil Elwell , Eric Anholt , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, Nathan Chancellor , Hoegeun Kwon , Nicolas Saenz Julienne Content-Type: multipart/mixed; boundary="===============3348424004181899241==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3348424004181899241== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jq7qpluuzzoo6pw4" Content-Disposition: inline --jq7qpluuzzoo6pw4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote: > Hi Stefan, >=20 > On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote: > > Am 30.09.20 um 18:38 schrieb Nathan Chancellor: > > > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote: > > >> Hi Nathan, > > >> > > >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote: > > >>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote: > > >>>> Now that all the drivers have been adjusted for it, let's bring in= the > > >>>> necessary device tree changes. > > >>>> > > >>>> The VEC and PV3 are left out for now, since it will require a more= specific > > >>>> clock setup. > > >>>> > > >>>> Reviewed-by: Dave Stevenson > > >>>> Tested-by: Chanwoo Choi > > >>>> Tested-by: Hoegeun Kwon > > >>>> Tested-by: Stefan Wahren > > >>>> Signed-off-by: Maxime Ripard > > >>> Apologies if this has already been reported or have a solution but = this > > >>> patch (and presumably series) breaks output to the serial console a= fter > > >>> a certain point during init. On Raspbian, I see systemd startup mes= sages > > >>> then the output just turns into complete garbage. It looks like this > > >>> patch is merged first in linux-next, which is why my bisect fell on= the > > >>> DRM merge. I am happy to provide whatever information could be help= ful > > >>> for debugging this. I am on the latest version of the firmware > > >>> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241). > > >> Unfortunately, the miniUART is in the same clock tree than the core > > >> clock and will thus have those kind of issues when the core clock is > > >> changed (which is also something that one should expect when using t= he > > >> DRM or other drivers). > > >> > > >> The only real workaround there would be to switch to one of the PL011 > > >> UARTs. I guess we can also somehow make the UART react to the core c= lock > > >> frequency changes, but that's going to require some effort > > >> > > >> Maxime > > > Ack, thank you for the reply! There does not really seem to be a whole > > > ton of documentation around using one of the other PL011 UARTs so for > > > now, I will just revert this commit locally. > >=20 > > there was a patch series & discussion about this topic, but we finally > > didn't find a rock solid solution. > >=20 > > You can have a look at "[RFC 5/5] serial: 8250: bcm2835aux: add notifier > > to follow clock changes" from 3.4.2019 on linux-rpi-kernel. >=20 > I couldn't find that discussion on the archive, but based on the title I > guess there's some patches that have been merged this cycle for the 8250 > driver to do just that (868f3ee6e452 ("serial: 8250: Add 8250 port clock > update method") and cc816969d7b5 ("serial: 8250_dw: Fix common clocks > usage race condition")). >=20 > However, I'm not entirely sure the clock notifier works in our case with > the firmware / MMIO clocks duality I was a bit intrigued by this, so I looked into it, and it seems that it's worth that it used to be. The core clock is supposed to be running at 500 Mhz in most cases, and that's what we're setting so it shouldn't cause any pratical issue. However, it looks like on my board now the firmware reports that the core clock is running at either 311MHz or 233MHz with hdmi_enable_4k60 (which seems odd?) and that contradicts the documentation here: https://www.raspberrypi.org/documentation/configuration/config-txt/overcloc= king.md Linux then comes in, changes the frequency to 500MHz and breaks the UART. So either the doc is wrong, or the clock driver is. vcgencmd measure_clock core reports that it's indeed 233Mhz and I'm running a year-old firmware (built on the 2019-11-29), so I'd be inclined to think that the doc is wrong here or we're misinterpreting something. Dave, Tim, any idea? Thanks! Maxime --jq7qpluuzzoo6pw4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX3WZKgAKCRDj7w1vZxhR xfXhAQDFSw1QCBRSnfLzXomPVG2hE9XEQuCVtTqq9KDlhYul7QEAyzFgfN7GAZQK DDQsA+8Ty05gotg13ZSiA3io2xi10wI= =fxeW -----END PGP SIGNATURE----- --jq7qpluuzzoo6pw4-- --===============3348424004181899241== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============3348424004181899241==-- 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 X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12CC0C4727F for ; Fri, 2 Oct 2020 07:03:04 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 70986206DD for ; Fri, 2 Oct 2020 07:03:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70986206DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 001FE6E08E; Fri, 2 Oct 2020 07:02:50 +0000 (UTC) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by gabe.freedesktop.org (Postfix) with ESMTPS id 22C696E897 for ; Thu, 1 Oct 2020 08:54:08 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 8589B580289; Thu, 1 Oct 2020 04:54:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 01 Oct 2020 04:54:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=aCuInhZvme0gvNR2gwI/zQvtYmr lJy91lYSNBnXMZcY=; b=Ss8leWBrTndXP2dNlMLxQ8EvPcUa3y0saYFq9O9y8hJ 7w/SSZ+E6/4u5srBu7bP4XKLdGI9ZmP4HalWrsHQ7/dHjAzCcAst0wAJqme7s9nP 9jIzqUeP1xJhC5fHhGQ7Q8ulClZZ6gtWOshTLPUascdSQqUpvIPcjnCr+iILpBVZ etR1Tig+hywUufMsgebRKB3WzwV9LAc3SQMruPwgxqjWlkXU/pZ17Pc/cxS3FJVe GUquXl82pjekK+kh/qbbdqUu6MjfI5wDSHSMQCdbabmqiJCgqUIM+Gxm6C9VO2Is kiR90qIcB0Urfv00mZ2SE2mz/SqXoiTiegwtfW0PrTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=aCuInh Zvme0gvNR2gwI/zQvtYmrlJy91lYSNBnXMZcY=; b=grEj/yD/j2hIrzAecibb4R 8NFSVpkyVwITqSLHhnxJnNMt29Bc48Sbs0eo91xQDCHk38Vmq/hFgQlTUiR3EbQW 6cHpULy60f7ZfzU/7IiRBgi6P6we6mP4w4KKkKSkJS/y1NPvh4T/hepE3YvvL0cf n9J4lrwrpiKVIODYztie0mbZrBN1VtYsRh1IgciYRvdUXlbvE6Em6vsnwpR47afR vIm3uwEgJsWXa9ovQvA2XynCeV0MKJMWWjWtc+eZZi7jLzBSU5XlyeeTBI+8pWdi HiqdXtjIUb96zvlCDGwPNSUs2iugSEWWUxIhNeO6PxalNGSbTnTT5RJoPc9v/suw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeeggddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpedtleegieefhfeflefgjedtueeuudeljeetgeeggeekjedulefhuddvveeifefg leenucffohhmrghinheprhgrshhpsggvrhhrhihpihdrohhrghenucfkphepledtrdekle drieekrdejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A3CA3280059; Thu, 1 Oct 2020 04:54:04 -0400 (EDT) Date: Thu, 1 Oct 2020 10:54:02 +0200 From: Maxime Ripard To: Stefan Wahren Subject: Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline Message-ID: <20201001085402.t6mzzwzplviunhoc@gilmour.lan> References: <20200929221526.GA1370981@ubuntu-m3-large-x86> <20200930140758.gummt3umouva3wyu@gilmour.lan> <20200930163823.GA237050@ubuntu-m3-large-x86> <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> MIME-Version: 1.0 In-Reply-To: <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> X-Mailman-Approved-At: Fri, 02 Oct 2020 07:02:50 +0000 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: linux-arm-kernel@lists.infradead.org, Chanwoo Choi , Tim Gover , Dave Stevenson , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Phil Elwell , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, Nathan Chancellor , Hoegeun Kwon , Nicolas Saenz Julienne Content-Type: multipart/mixed; boundary="===============1821392943==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============1821392943== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jq7qpluuzzoo6pw4" Content-Disposition: inline --jq7qpluuzzoo6pw4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote: > Hi Stefan, >=20 > On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote: > > Am 30.09.20 um 18:38 schrieb Nathan Chancellor: > > > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote: > > >> Hi Nathan, > > >> > > >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote: > > >>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote: > > >>>> Now that all the drivers have been adjusted for it, let's bring in= the > > >>>> necessary device tree changes. > > >>>> > > >>>> The VEC and PV3 are left out for now, since it will require a more= specific > > >>>> clock setup. > > >>>> > > >>>> Reviewed-by: Dave Stevenson > > >>>> Tested-by: Chanwoo Choi > > >>>> Tested-by: Hoegeun Kwon > > >>>> Tested-by: Stefan Wahren > > >>>> Signed-off-by: Maxime Ripard > > >>> Apologies if this has already been reported or have a solution but = this > > >>> patch (and presumably series) breaks output to the serial console a= fter > > >>> a certain point during init. On Raspbian, I see systemd startup mes= sages > > >>> then the output just turns into complete garbage. It looks like this > > >>> patch is merged first in linux-next, which is why my bisect fell on= the > > >>> DRM merge. I am happy to provide whatever information could be help= ful > > >>> for debugging this. I am on the latest version of the firmware > > >>> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241). > > >> Unfortunately, the miniUART is in the same clock tree than the core > > >> clock and will thus have those kind of issues when the core clock is > > >> changed (which is also something that one should expect when using t= he > > >> DRM or other drivers). > > >> > > >> The only real workaround there would be to switch to one of the PL011 > > >> UARTs. I guess we can also somehow make the UART react to the core c= lock > > >> frequency changes, but that's going to require some effort > > >> > > >> Maxime > > > Ack, thank you for the reply! There does not really seem to be a whole > > > ton of documentation around using one of the other PL011 UARTs so for > > > now, I will just revert this commit locally. > >=20 > > there was a patch series & discussion about this topic, but we finally > > didn't find a rock solid solution. > >=20 > > You can have a look at "[RFC 5/5] serial: 8250: bcm2835aux: add notifier > > to follow clock changes" from 3.4.2019 on linux-rpi-kernel. >=20 > I couldn't find that discussion on the archive, but based on the title I > guess there's some patches that have been merged this cycle for the 8250 > driver to do just that (868f3ee6e452 ("serial: 8250: Add 8250 port clock > update method") and cc816969d7b5 ("serial: 8250_dw: Fix common clocks > usage race condition")). >=20 > However, I'm not entirely sure the clock notifier works in our case with > the firmware / MMIO clocks duality I was a bit intrigued by this, so I looked into it, and it seems that it's worth that it used to be. The core clock is supposed to be running at 500 Mhz in most cases, and that's what we're setting so it shouldn't cause any pratical issue. However, it looks like on my board now the firmware reports that the core clock is running at either 311MHz or 233MHz with hdmi_enable_4k60 (which seems odd?) and that contradicts the documentation here: https://www.raspberrypi.org/documentation/configuration/config-txt/overcloc= king.md Linux then comes in, changes the frequency to 500MHz and breaks the UART. So either the doc is wrong, or the clock driver is. vcgencmd measure_clock core reports that it's indeed 233Mhz and I'm running a year-old firmware (built on the 2019-11-29), so I'd be inclined to think that the doc is wrong here or we're misinterpreting something. Dave, Tim, any idea? Thanks! Maxime --jq7qpluuzzoo6pw4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX3WZKgAKCRDj7w1vZxhR xfXhAQDFSw1QCBRSnfLzXomPVG2hE9XEQuCVtTqq9KDlhYul7QEAyzFgfN7GAZQK DDQsA+8Ty05gotg13ZSiA3io2xi10wI= =fxeW -----END PGP SIGNATURE----- --jq7qpluuzzoo6pw4-- --===============1821392943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1821392943==--