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 56850C4727F for ; Thu, 1 Oct 2020 10:16:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DE95C22204 for ; Thu, 1 Oct 2020 10:16:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=raspberrypi.com header.i=@raspberrypi.com header.b="beAv55Us" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731880AbgJAKP7 (ORCPT ); Thu, 1 Oct 2020 06:15:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725938AbgJAKP7 (ORCPT ); Thu, 1 Oct 2020 06:15:59 -0400 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE2A6C0613D0 for ; Thu, 1 Oct 2020 03:15:58 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id b22so5839751lfs.13 for ; Thu, 01 Oct 2020 03:15:58 -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=sbHB4UppKAenF5cuB/vMr8n45MQRc8w9Jto0vU1UBGI=; b=beAv55UsVyfGF0QS4DSb8YtWr0/kLHdy8m7Y/p3vuAvNYpKj8Er+VNcAzrvV5a2nlI P5CCC9NT2Dh7rpn0ytCR0SxxE/nYyM6ucU+QWymp1zSTe6mTGqB5eV7x7+C+eCFEOnE9 3ZBduzCDBKM3GdWJTemquWib0vXuxiJ7ShPVqqMhQKcwJ2k6mIvHB2tU7jtn0D03ThEu 2QXjy7xpu9fmyJ2oujUuQVzqAr3wReGopQc27sm263SGrZfj2VBYSxrhde1YMimP/ZxN IPLAxgUNwbuO4WrNPX5W5PaD6ohanEcXYl0PxyVM/bEukSoOEYvS7sviOJqjQ5GYVZYo aa6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sbHB4UppKAenF5cuB/vMr8n45MQRc8w9Jto0vU1UBGI=; b=cGyMRPJKYl2sQeDxFtLR9xz1blq5bDrDwyykZMecW7LZzhsKU0G1SeQO+yDBFa+UTv 8rUIKDcTg10Vb+F59kmdiQlI68W+U3pfiOL3tD3F8HUjrWYfwb5E8Ve9aF7I8UEB+Zug cICwoLawjfx3hRJvhHIo5h4qP0/+Skq9OPEFycxsl1w63CdpwpW8LDN6yveQNiq0padk wKr1fWXUibr0CU+kQUDgA2m7AAqCGj+gL0I9n4yJjBqWbY7FYV94r1Nc0xB05qPOvrWR iGBH3L9NWc0y9MxvYi0+dBS+qPSV7VIPkYb8F69lwwdhSB4z0uwHDJdJcvdF/ucyXXni vUeg== X-Gm-Message-State: AOAM530Bn6MctASk+4JSoMYOsfdqDJPvpRfCVKZWse3dV8IcDsJUsgwP J3pHElWDfbocpSDesyrHR6venWkgmDubFpLYW6oyow== X-Google-Smtp-Source: ABdhPJz+dSG1WLw5ugB6n7HEwN0s6TlyMWv5/7+mvXT01Jl0M1MTND1yxApBDlypSSLWkuxoRZKti8z/Eofzfl+gmbc= X-Received: by 2002:a19:8044:: with SMTP id b65mr2152189lfd.366.1601547357111; Thu, 01 Oct 2020 03:15:57 -0700 (PDT) MIME-Version: 1.0 References: <20200929221526.GA1370981@ubuntu-m3-large-x86> <20200930140758.gummt3umouva3wyu@gilmour.lan> <20200930163823.GA237050@ubuntu-m3-large-x86> <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> <20201001085402.t6mzzwzplviunhoc@gilmour.lan> In-Reply-To: <20201001085402.t6mzzwzplviunhoc@gilmour.lan> From: Tim Gover Date: Thu, 1 Oct 2020 11:15:46 +0100 Message-ID: Subject: Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline To: Maxime Ripard Cc: Stefan Wahren , Nathan Chancellor , Nicolas Saenz Julienne , Eric Anholt , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC VCO to support a core-frequency of 550 MHz which is the minimum frequency required by the HVS at 4Kp60. The side effect is that if the display clock requirements are lower than 4Kp60 then you will see different core frequencies selected by DVFS. If enable_uart=1 and the mini-uart is selected (default unless bluetooth is disabled) then the firmware will pin the core-frequency to either core_freq max (500 or 550). Although, I think there is a way of pinning it to a lower fixed frequency. The table in overclocking.md defines options for setting the maximum core frequency but unless core_freq_min is specified DVFS will automatically pick the lowest idle frequency required by the display resolution. On Thu, 1 Oct 2020 at 09:54, Maxime Ripard wrote: > > On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote: > > Hi Stefan, > > > > 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 after > > > >>> a certain point during init. On Raspbian, I see systemd startup messages > > > >>> 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 helpful > > > >>> 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 the > > > >> 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 clock > > > >> 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. > > > > > > there was a patch series & discussion about this topic, but we finally > > > didn't find a rock solid solution. > > > > > > 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. > > > > 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")). > > > > 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/overclocking.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 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 3D5D8C4727F for ; Thu, 1 Oct 2020 10:17:38 +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 D4A0120838 for ; Thu, 1 Oct 2020 10:17:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OczovjUg"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=raspberrypi.com header.i=@raspberrypi.com header.b="beAv55Us" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4A0120838 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=raspberrypi.com 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id: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=5SSffy38PBznP2dZPgAKRaSvUHahQ8jnzcD93LxzgII=; b=OczovjUgALmJwiB/6p04GdkuA LFZbL75JK0Vf+94LNZcEQHXPqNGeKHNcTpel25xLbHoA2/1XjFuWW8Kst+eEwM+ttEsbQLdxIszMY 3bbu5uSQyq9JJ7V+I1UnSerDs0Z1Vlw5DJ1DA286JAHirYtjTtjb5Jz7Qorm9l6A55zE0cXjk+VQc 9zAuyLUsAeb84c2ZYbWbEmA5yjTFY1wOCj1SAbumuL8ausa0xPva48AClWlposZOH3ot9jNw+zpNv I6kkPER6KEum54krRcIpRO+G+iJamBHRnkTAxj4nRg40ugq5OTo4eW0Iw1JTy0CCmWU7mIrNSTy// t5qrPNK/g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNvd5-00022e-Oi; Thu, 01 Oct 2020 10:16:03 +0000 Received: from mail-lf1-x144.google.com ([2a00:1450:4864:20::144]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNvd2-000218-76 for linux-arm-kernel@lists.infradead.org; Thu, 01 Oct 2020 10:16:01 +0000 Received: by mail-lf1-x144.google.com with SMTP id z19so5889550lfr.4 for ; Thu, 01 Oct 2020 03:15:58 -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=sbHB4UppKAenF5cuB/vMr8n45MQRc8w9Jto0vU1UBGI=; b=beAv55UsVyfGF0QS4DSb8YtWr0/kLHdy8m7Y/p3vuAvNYpKj8Er+VNcAzrvV5a2nlI P5CCC9NT2Dh7rpn0ytCR0SxxE/nYyM6ucU+QWymp1zSTe6mTGqB5eV7x7+C+eCFEOnE9 3ZBduzCDBKM3GdWJTemquWib0vXuxiJ7ShPVqqMhQKcwJ2k6mIvHB2tU7jtn0D03ThEu 2QXjy7xpu9fmyJ2oujUuQVzqAr3wReGopQc27sm263SGrZfj2VBYSxrhde1YMimP/ZxN IPLAxgUNwbuO4WrNPX5W5PaD6ohanEcXYl0PxyVM/bEukSoOEYvS7sviOJqjQ5GYVZYo aa6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sbHB4UppKAenF5cuB/vMr8n45MQRc8w9Jto0vU1UBGI=; b=SSxkwQy1rPZVXCOk9TSjLQJMm6DXnmU1F3y0rMbhG65VFp7PeDZHJjjrcybeMPFR3x +zkzzNvt65wFNwyEoQgg0sd1AmnYnku//PoAwnyUdqTlaG2taFe3W1kIIu2HZCe3k2Od lOqfx9vKJ457KkjjnwYaFi0LHlHDJvq4sNfOg00wKJTqfuervttzUJSQaDizQRMwAmmL 9uxK1a/b+jshNGJVRAbRN0tA7ec7lNB2hdEzZB7EUUeXZaOBVlURYlL2t0S3g11Xb8oI vPoi/I7mltsNXwDItTrKnuyVXNRogbHkGRsuAQLKrkLacpSsD6vWSd/YZtbeQUiBVfPZ jKlA== X-Gm-Message-State: AOAM532O6uemb+dENU+6fvpoIP1z/F0BgWIrR8/IXjkgX+ZJGVkOEy2p rPy/8NN/5VFNae+8Nnj00svdxVKkaSCIOfJhICdRkQ== X-Google-Smtp-Source: ABdhPJz+dSG1WLw5ugB6n7HEwN0s6TlyMWv5/7+mvXT01Jl0M1MTND1yxApBDlypSSLWkuxoRZKti8z/Eofzfl+gmbc= X-Received: by 2002:a19:8044:: with SMTP id b65mr2152189lfd.366.1601547357111; Thu, 01 Oct 2020 03:15:57 -0700 (PDT) MIME-Version: 1.0 References: <20200929221526.GA1370981@ubuntu-m3-large-x86> <20200930140758.gummt3umouva3wyu@gilmour.lan> <20200930163823.GA237050@ubuntu-m3-large-x86> <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> <20201001085402.t6mzzwzplviunhoc@gilmour.lan> In-Reply-To: <20201001085402.t6mzzwzplviunhoc@gilmour.lan> From: Tim Gover Date: Thu, 1 Oct 2020 11:15:46 +0100 Message-ID: Subject: Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline To: Maxime Ripard X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201001_061600_331327_02033A6C X-CRM114-Status: GOOD ( 45.14 ) 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: Stefan Wahren , Chanwoo Choi , 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 , linux-arm-kernel@lists.infradead.org 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 hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC VCO to support a core-frequency of 550 MHz which is the minimum frequency required by the HVS at 4Kp60. The side effect is that if the display clock requirements are lower than 4Kp60 then you will see different core frequencies selected by DVFS. If enable_uart=1 and the mini-uart is selected (default unless bluetooth is disabled) then the firmware will pin the core-frequency to either core_freq max (500 or 550). Although, I think there is a way of pinning it to a lower fixed frequency. The table in overclocking.md defines options for setting the maximum core frequency but unless core_freq_min is specified DVFS will automatically pick the lowest idle frequency required by the display resolution. On Thu, 1 Oct 2020 at 09:54, Maxime Ripard wrote: > > On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote: > > Hi Stefan, > > > > 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 after > > > >>> a certain point during init. On Raspbian, I see systemd startup messages > > > >>> 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 helpful > > > >>> 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 the > > > >> 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 clock > > > >> 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. > > > > > > there was a patch series & discussion about this topic, but we finally > > > didn't find a rock solid solution. > > > > > > 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. > > > > 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")). > > > > 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/overclocking.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 1E519C4727F for ; Fri, 2 Oct 2020 07:03:15 +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 9A559206DD for ; Fri, 2 Oct 2020 07:03:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=raspberrypi.com header.i=@raspberrypi.com header.b="beAv55Us" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A559206DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=raspberrypi.com 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 2482C6E914; Fri, 2 Oct 2020 07:02:55 +0000 (UTC) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by gabe.freedesktop.org (Postfix) with ESMTPS id BFDDE6E16F for ; Thu, 1 Oct 2020 10:15:58 +0000 (UTC) Received: by mail-lf1-x144.google.com with SMTP id q8so5872271lfb.6 for ; Thu, 01 Oct 2020 03:15:58 -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=sbHB4UppKAenF5cuB/vMr8n45MQRc8w9Jto0vU1UBGI=; b=beAv55UsVyfGF0QS4DSb8YtWr0/kLHdy8m7Y/p3vuAvNYpKj8Er+VNcAzrvV5a2nlI P5CCC9NT2Dh7rpn0ytCR0SxxE/nYyM6ucU+QWymp1zSTe6mTGqB5eV7x7+C+eCFEOnE9 3ZBduzCDBKM3GdWJTemquWib0vXuxiJ7ShPVqqMhQKcwJ2k6mIvHB2tU7jtn0D03ThEu 2QXjy7xpu9fmyJ2oujUuQVzqAr3wReGopQc27sm263SGrZfj2VBYSxrhde1YMimP/ZxN IPLAxgUNwbuO4WrNPX5W5PaD6ohanEcXYl0PxyVM/bEukSoOEYvS7sviOJqjQ5GYVZYo aa6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sbHB4UppKAenF5cuB/vMr8n45MQRc8w9Jto0vU1UBGI=; b=ORP7Bin3OzW8o7e1P3axg/Wngm8lfsYTIJ9IKZNEX/5BDSBwWBxfFRreklB8bK4ME5 uIHkcAX6/+8s0hXLDwSaPFRQji4r2z6aFRswISZt16iH7seBdneLbo+6v56DDV48+WR2 Q9l/1IpwI5VhKPeSamZTFq6Xe8fRJ7+CJ7ACwcrp1f7q4zVvF/SflbKQMSWql92F7AVn t4KGhNVq5fOOWltjmY6aQLfgUGDorCvt+wymcR07gGUG8/tRisw/WiyRtQb3nmO0b+mL ce/2Q8ebWzwfuRgIw7kj4pRUwfSt2K4aC5x1FfyYxN1sBCHaNMIWqa4t+bQEYgQNe0dF TPxQ== X-Gm-Message-State: AOAM530NiqxyowZ79ZEJuk9UpCl9CRs3LBeTs32GH6Id2RcWr9e0WNbY 1Zm6pTvK2lYdB3MKT70GlwS78u/y97L0LySLMPIAuA== X-Google-Smtp-Source: ABdhPJz+dSG1WLw5ugB6n7HEwN0s6TlyMWv5/7+mvXT01Jl0M1MTND1yxApBDlypSSLWkuxoRZKti8z/Eofzfl+gmbc= X-Received: by 2002:a19:8044:: with SMTP id b65mr2152189lfd.366.1601547357111; Thu, 01 Oct 2020 03:15:57 -0700 (PDT) MIME-Version: 1.0 References: <20200929221526.GA1370981@ubuntu-m3-large-x86> <20200930140758.gummt3umouva3wyu@gilmour.lan> <20200930163823.GA237050@ubuntu-m3-large-x86> <20201001064843.dlewcu3b7dvqanyy@gilmour.lan> <20201001085402.t6mzzwzplviunhoc@gilmour.lan> In-Reply-To: <20201001085402.t6mzzwzplviunhoc@gilmour.lan> From: Tim Gover Date: Thu, 1 Oct 2020 11:15:46 +0100 Message-ID: Subject: Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline To: Maxime Ripard 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: Stefan Wahren , Chanwoo Choi , 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 , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC VCO to support a core-frequency of 550 MHz which is the minimum frequency required by the HVS at 4Kp60. The side effect is that if the display clock requirements are lower than 4Kp60 then you will see different core frequencies selected by DVFS. If enable_uart=1 and the mini-uart is selected (default unless bluetooth is disabled) then the firmware will pin the core-frequency to either core_freq max (500 or 550). Although, I think there is a way of pinning it to a lower fixed frequency. The table in overclocking.md defines options for setting the maximum core frequency but unless core_freq_min is specified DVFS will automatically pick the lowest idle frequency required by the display resolution. On Thu, 1 Oct 2020 at 09:54, Maxime Ripard wrote: > > On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote: > > Hi Stefan, > > > > 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 after > > > >>> a certain point during init. On Raspbian, I see systemd startup messages > > > >>> 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 helpful > > > >>> 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 the > > > >> 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 clock > > > >> 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. > > > > > > there was a patch series & discussion about this topic, but we finally > > > didn't find a rock solid solution. > > > > > > 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. > > > > 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")). > > > > 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/overclocking.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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel