From 49ac3a29168c35996898d1ea3feee70d4d0952aa Mon Sep 17 00:00:00 2001 From: Peter Robinson Date: Fri, 3 Apr 2020 12:42:34 +0100 Subject: Raspberry Pi HDMI mode validation fix --- drm-vc4-Fix-HDMI-mode-validation.patch | 65 ++++++++++++++++++++++++++++++++++ kernel.spec | 5 +++ 2 files changed, 70 insertions(+) create mode 100644 drm-vc4-Fix-HDMI-mode-validation.patch diff --git a/drm-vc4-Fix-HDMI-mode-validation.patch b/drm-vc4-Fix-HDMI-mode-validation.patch new file mode 100644 index 000000000..224c8fa27 --- /dev/null +++ b/drm-vc4-Fix-HDMI-mode-validation.patch @@ -0,0 +1,65 @@ +From patchwork Thu Mar 26 12:20:01 2020 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: drm/vc4: Fix HDMI mode validation +From: Nicolas Saenz Julienne +X-Patchwork-Id: 358980 +Message-Id: <20200326122001.22215-1-nsaenzjulienne@suse.de> +To: Eric Anholt , + Daniel Vetter +Cc: Stefan Wahren , f.fainelli@gmail.com, + Dave Stevenson , + David Airlie , linux-kernel@vger.kernel.org, + dri-devel@lists.freedesktop.org, maxime@cerno.tech, + Nicolas Saenz Julienne , + linux-rpi-kernel@lists.infradead.org +Date: Thu, 26 Mar 2020 13:20:01 +0100 + +Current mode validation impedes setting up some video modes which should +be supported otherwise. Namely 1920x1200@60Hz. + +Fix this by lowering the minimum HDMI state machine clock to pixel clock +ratio allowed. + +Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks") +Reported-by: Stefan Wahren +Suggested-by: Dave Stevenson +Signed-off-by: Nicolas Saenz Julienne +Reviewed-by: Maxime Ripard +--- + drivers/gpu/drm/vc4/vc4_hdmi.c | 20 ++++++++++++++++---- + 1 file changed, 16 insertions(+), 4 deletions(-) + +diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c +index cea18dc15f77..340719238753 100644 +--- a/drivers/gpu/drm/vc4/vc4_hdmi.c ++++ b/drivers/gpu/drm/vc4/vc4_hdmi.c +@@ -681,11 +681,23 @@ static enum drm_mode_status + vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc, + const struct drm_display_mode *mode) + { +- /* HSM clock must be 108% of the pixel clock. Additionally, +- * the AXI clock needs to be at least 25% of pixel clock, but +- * HSM ends up being the limiting factor. ++ /* ++ * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must ++ * be faster than pixel clock, infinitesimally faster, tested in ++ * simulation. Otherwise, exact value is unimportant for HDMI ++ * operation." This conflicts with bcm2835's vc4 documentation, which ++ * states HSM's clock has to be at least 108% of the pixel clock. ++ * ++ * Real life tests reveal that vc4's firmware statement holds up, and ++ * users are able to use pixel clocks closer to HSM's, namely for ++ * 1920x1200@60Hz. So it was decided to have leave a 1% margin between ++ * both clocks. Which, for RPi0-3 implies a maximum pixel clock of ++ * 162MHz. ++ * ++ * Additionally, the AXI clock needs to be at least 25% of ++ * pixel clock, but HSM ends up being the limiting factor. + */ +- if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100)) ++ if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100)) + return MODE_CLOCK_HIGH; + + return MODE_OK; diff --git a/kernel.spec b/kernel.spec index 768f59205..281fc8849 100644 --- a/kernel.spec +++ b/kernel.spec @@ -828,6 +828,8 @@ Patch311: USB-pci-quirks-Add-Raspberry-Pi-4-quirk.patch Patch312: bcm2835-irqchip-Quiesce-IRQs-left-enabled-by-bootloader.patch # https://patchwork.kernel.org/patch/11420129/ Patch313: ARM-dts-bcm2711-Move-emmc2-into-its-own-bus.patch +# https://patchwork.freedesktop.org/patch/358980/ +Patch314: drm-vc4-Fix-HDMI-mode-validation.patch # Tegra bits # https://www.spinics.net/lists/linux-tegra/msg48152.html @@ -2993,6 +2995,9 @@ fi # # %changelog +* Fri Apr 3 2020 Peter Robinson +- Raspberry Pi HDMI mode validation fix + * Thu Apr 02 2020 Jeremy Cline - 5.6.2-300 - Linux v5.6.2 -- cgit From 52af994213ceed8277caaff2b31bcc43663f03b0 Mon Sep 17 00:00:00 2001 From: Peter Robinson Date: Mon, 6 Apr 2020 19:39:32 +0100 Subject: Raspberry Pi 4 rev 1.2 mmc fix --- ...sdhci-iproc-Add-custom-set_power-callback.patch | 374 +++++++++++++++++++++ ...cm2835-serial-8250_early-support-aux-uart.patch | 47 +++ kernel.spec | 7 +- 3 files changed, 427 insertions(+), 1 deletion(-) create mode 100644 arm-bcm2711-mmc-sdhci-iproc-Add-custom-set_power-callback.patch create mode 100644 arm-bcm2835-serial-8250_early-support-aux-uart.patch diff --git a/arm-bcm2711-mmc-sdhci-iproc-Add-custom-set_power-callback.patch b/arm-bcm2711-mmc-sdhci-iproc-Add-custom-set_power-callback.patch new file mode 100644 index 000000000..8c7a43185 --- /dev/null +++ b/arm-bcm2711-mmc-sdhci-iproc-Add-custom-set_power-callback.patch @@ -0,0 +1,374 @@ +From 6c92ae1e452ff3f4648b1450c9a3233a2ca53feb Mon Sep 17 00:00:00 2001 +From: Nicolas Saenz Julienne +Date: Fri, 6 Mar 2020 18:44:03 +0100 +Subject: mmc: sdhci: Introduce sdhci_set_power_and_bus_voltage() + +Some controllers diverge from the standard way of setting power and need +their bus voltage register to be configured regardless of the whether +they use regulators. As this is a common pattern across sdhci hosts, +create a helper function. + +Signed-off-by: Nicolas Saenz Julienne +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/20200306174413.20634-2-nsaenzjulienne@suse.de +Signed-off-by: Ulf Hansson +--- + drivers/mmc/host/sdhci.c | 19 +++++++++++++++++++ + drivers/mmc/host/sdhci.h | 3 +++ + 2 files changed, 22 insertions(+) + +diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c +index c59566363a42..525e0c971c6a 100644 +--- a/drivers/mmc/host/sdhci.c ++++ b/drivers/mmc/host/sdhci.c +@@ -2010,6 +2010,25 @@ void sdhci_set_power(struct sdhci_host *host, unsigned char mode, + } + EXPORT_SYMBOL_GPL(sdhci_set_power); + ++/* ++ * Some controllers need to configure a valid bus voltage on their power ++ * register regardless of whether an external regulator is taking care of power ++ * supply. This helper function takes care of it if set as the controller's ++ * sdhci_ops.set_power callback. ++ */ ++void sdhci_set_power_and_bus_voltage(struct sdhci_host *host, ++ unsigned char mode, ++ unsigned short vdd) ++{ ++ if (!IS_ERR(host->mmc->supply.vmmc)) { ++ struct mmc_host *mmc = host->mmc; ++ ++ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd); ++ } ++ sdhci_set_power_noreg(host, mode, vdd); ++} ++EXPORT_SYMBOL_GPL(sdhci_set_power_and_bus_voltage); ++ + /*****************************************************************************\ + * * + * MMC callbacks * +diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h +index 249635692112..851b81565f46 100644 +--- a/drivers/mmc/host/sdhci.h ++++ b/drivers/mmc/host/sdhci.h +@@ -772,6 +772,9 @@ void sdhci_set_clock(struct sdhci_host *host, unsigned int clock); + void sdhci_enable_clk(struct sdhci_host *host, u16 clk); + void sdhci_set_power(struct sdhci_host *host, unsigned char mode, + unsigned short vdd); ++void sdhci_set_power_and_bus_voltage(struct sdhci_host *host, ++ unsigned char mode, ++ unsigned short vdd); + void sdhci_set_power_noreg(struct sdhci_host *host, unsigned char mode, + unsigned short vdd); + void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq); +-- +cgit 1.2-0.3.lf.el7 +From f87391eec2c5f54269e64d655da19f2c32515e4c Mon Sep 17 00:00:00 2001 +From: Nicolas Saenz Julienne +Date: Fri, 6 Mar 2020 18:44:11 +0100 +Subject: mmc: sdhci: iproc: Add custom set_power() callback for bcm2711 + +The controller needs a valid bus voltage in its power register +regardless of whether an external regulator is taking care of the power +supply. + +The sdhci core already provides a helper function for this, +sdhci_set_power_and_bus_voltage(), so create a bcm2711 specific 'struct +sdhci_ops' which makes use of it. + +Signed-off-by: Nicolas Saenz Julienne +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/20200306174413.20634-10-nsaenzjulienne@suse.de +Signed-off-by: Ulf Hansson +--- + drivers/mmc/host/sdhci-iproc.c | 17 ++++++++++++++++- + 1 file changed, 16 insertions(+), 1 deletion(-) + +diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c +index f4f5f0a70cda..225603148d7d 100644 +--- a/drivers/mmc/host/sdhci-iproc.c ++++ b/drivers/mmc/host/sdhci-iproc.c +@@ -261,9 +261,24 @@ static const struct sdhci_iproc_data bcm2835_data = { + .mmc_caps = 0x00000000, + }; + ++static const struct sdhci_ops sdhci_iproc_bcm2711_ops = { ++ .read_l = sdhci_iproc_readl, ++ .read_w = sdhci_iproc_readw, ++ .read_b = sdhci_iproc_readb, ++ .write_l = sdhci_iproc_writel, ++ .write_w = sdhci_iproc_writew, ++ .write_b = sdhci_iproc_writeb, ++ .set_clock = sdhci_set_clock, ++ .set_power = sdhci_set_power_and_bus_voltage, ++ .get_max_clock = sdhci_iproc_get_max_clock, ++ .set_bus_width = sdhci_set_bus_width, ++ .reset = sdhci_reset, ++ .set_uhs_signaling = sdhci_set_uhs_signaling, ++}; ++ + static const struct sdhci_pltfm_data sdhci_bcm2711_pltfm_data = { + .quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12, +- .ops = &sdhci_iproc_32only_ops, ++ .ops = &sdhci_iproc_bcm2711_ops, + }; + + static const struct sdhci_iproc_data bcm2711_data = { +-- +cgit 1.2-0.3.lf.el7 +From patchwork Fri Mar 6 17:44:12 2020 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +X-Patchwork-Submitter: Nicolas Saenz Julienne +X-Patchwork-Id: 11424593 +Return-Path: + +Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org + [172.30.200.123]) + by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9D86014E3 + for ; + Fri, 6 Mar 2020 17:46:55 +0000 (UTC) +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 mail.kernel.org (Postfix) with ESMTPS id 7BFCB2072A + for ; + Fri, 6 Mar 2020 17:46:55 +0000 (UTC) +Authentication-Results: mail.kernel.org; + dkim=pass (2048-bit key) header.d=lists.infradead.org + header.i=@lists.infradead.org header.b="YjdlKV21" +DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BFCB2072A +Authentication-Results: mail.kernel.org; + dmarc=none (p=none dis=none) header.from=suse.de +Authentication-Results: mail.kernel.org; + spf=none + smtp.mailfrom=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org +DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; + d=lists.infradead.org; s=bombadil.20170209; h=Sender: + Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: + List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: + Message-Id:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: + Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: + List-Owner; bh=uwmoUBe7WYtSPXJudhI4GM1SShwysP2rkzh9oA/iygA=; b=YjdlKV21P2YnYd + uFZk/zUDicQRMv6kHWHSeOubxKYNNZjuVUmkI6PWtCuEt37bz+3qPjaDWjY6QO0qR9wHKzxaPikjZ + upSKvBHf9jcYSON0gQhjCxZEGnfO3zrdObtnjdQFTTE9rJPiUXe+bIsvhqlNCO/5Xq4pXjSVR81Fw + IVfXtxtw0tmDjrN7VDqH+dhvUPrvLDRnXOHnolvQfQyuvyvSZ9I7Wn/c4fFJsZemBA7mjvORI7cTd + lVRuIqACikY2bT4Zh+ZtglOCFxtlNjCe60Dj94AnA/j51dvC8MHQOOD+HGKjGzKBwk5FONXjvKeUZ + kR8WGaZiQsG3hj3hzxyw==; +Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) + by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) + id 1jAH3k-0003wN-91; Fri, 06 Mar 2020 17:46:52 +0000 +Received: from mx2.suse.de ([195.135.220.15]) + by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) + id 1jAH1V-00085X-Ut; Fri, 06 Mar 2020 17:44:35 +0000 +X-Virus-Scanned: by amavisd-new at test-mx.suse.de +Received: from relay2.suse.de (unknown [195.135.220.254]) + by mx2.suse.de (Postfix) with ESMTP id 8906AACC2; + Fri, 6 Mar 2020 17:44:32 +0000 (UTC) +From: Nicolas Saenz Julienne +To: adrian.hunter@intel.com, linux-kernel@vger.kernel.org, + Rob Herring , + Nicolas Saenz Julienne +Subject: [PATCH v2 10/11] ARM: dts: bcm2711: Update expgpio's GPIO labels +Date: Fri, 6 Mar 2020 18:44:12 +0100 +Message-Id: <20200306174413.20634-11-nsaenzjulienne@suse.de> +X-Mailer: git-send-email 2.25.1 +In-Reply-To: <20200306174413.20634-1-nsaenzjulienne@suse.de> +References: <20200306174413.20634-1-nsaenzjulienne@suse.de> +MIME-Version: 1.0 +X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 +X-CRM114-CacheID: sfid-20200306_094434_171925_0978A2DC +X-CRM114-Status: GOOD ( 11.64 ) +X-Spam-Score: -2.3 (--) +X-Spam-Report: SpamAssassin version 3.4.3 on bombadil.infradead.org summary: + Content analysis details: (-2.3 points) + pts rule name description + ---- ---------------------- + -------------------------------------------------- + 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) + [195.135.220.15 listed in wl.mailspike.net] + -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, + medium trust [195.135.220.15 listed in list.dnswl.org] + 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record + -0.0 SPF_PASS SPF: sender matches SPF record + 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders +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@i2se.com, devicetree@vger.kernel.org, f.fainelli@gmail.com, + linux-mmc@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, + linux-rpi-kernel@lists.infradead.org, phil@raspberrypi.com, + linux-arm-kernel@lists.infradead.org +Sender: "linux-arm-kernel" +Errors-To: + linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org + +The 6th line of the GPIO expander is used to power the board's SD card. + +Signed-off-by: Nicolas Saenz Julienne +--- + arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts +index 1d4b589fe233..b0ea8233b636 100644 +--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts ++++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts +@@ -68,7 +68,7 @@ expgpio: gpio { + "GLOBAL_RESET", + "VDD_SD_IO_SEL", + "CAM_GPIO", +- "", ++ "SD_PWR_ON", + ""; + status = "okay"; + }; +From patchwork Fri Mar 6 17:44:13 2020 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +X-Patchwork-Submitter: Nicolas Saenz Julienne +X-Patchwork-Id: 11424599 +Return-Path: + +Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org + [172.30.200.123]) + by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A9E8E14BC + for ; + Fri, 6 Mar 2020 17:47:49 +0000 (UTC) +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 mail.kernel.org (Postfix) with ESMTPS id 86F7120656 + for ; + Fri, 6 Mar 2020 17:47:49 +0000 (UTC) +Authentication-Results: mail.kernel.org; + dkim=pass (2048-bit key) header.d=lists.infradead.org + header.i=@lists.infradead.org header.b="nK9IFX75" +DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 86F7120656 +Authentication-Results: mail.kernel.org; + dmarc=none (p=none dis=none) header.from=suse.de +Authentication-Results: mail.kernel.org; + spf=none + smtp.mailfrom=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org +DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; + d=lists.infradead.org; s=bombadil.20170209; h=Sender: + Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: + List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: + Message-Id:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: + Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: + List-Owner; bh=yrr+wQNcWoBzz3a/8/AcMlS2enrwpsgYIWUpL8bLv8o=; b=nK9IFX75hVaG6g + t8PhPIHJnIGtQxqZ65valF8dAq8JXeUle2mgnW5xdfa/YWcgzajD9/LaS1qMXKW7wDU/rQ0GbSW9t + +8F8v8NQzCf34sfHmFBEl30S1pJN/dQVJKJk0kmx6/P9N+ig3vAyMVsPsXq1Xij+OU0aU8SU1V+mE + nZnwLti9oSRWY6sNhg1MoHB2DNBt/FBNtROGqiXh13ngQTg8C/HgYapnJnXb+GjrutVM2DzH+i/tG + OtgGRm0XoLRz5QjavZZHPmlHUm8pMxfgllYbUvrESNgDT06vBiPj4idCN7X1XXxxoqPsP3/k8kido + Py713+dNVA1gqQEWqG1g==; +Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) + by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) + id 1jAH4a-0004vA-Os; Fri, 06 Mar 2020 17:47:44 +0000 +Received: from mx2.suse.de ([195.135.220.15]) + by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) + id 1jAH1W-00086J-W9; Fri, 06 Mar 2020 17:44:36 +0000 +X-Virus-Scanned: by amavisd-new at test-mx.suse.de +Received: from relay2.suse.de (unknown [195.135.220.254]) + by mx2.suse.de (Postfix) with ESMTP id 8D8E5AEC5; + Fri, 6 Mar 2020 17:44:33 +0000 (UTC) +From: Nicolas Saenz Julienne +To: adrian.hunter@intel.com, linux-kernel@vger.kernel.org, + Rob Herring , + Nicolas Saenz Julienne +Subject: [PATCH v2 11/11] ARM: dts: bcm2711: Add vmmc regulator in emmc2 +Date: Fri, 6 Mar 2020 18:44:13 +0100 +Message-Id: <20200306174413.20634-12-nsaenzjulienne@suse.de> +X-Mailer: git-send-email 2.25.1 +In-Reply-To: <20200306174413.20634-1-nsaenzjulienne@suse.de> +References: <20200306174413.20634-1-nsaenzjulienne@suse.de> +MIME-Version: 1.0 +X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 +X-CRM114-CacheID: sfid-20200306_094435_205829_20FE02CB +X-CRM114-Status: GOOD ( 10.34 ) +X-Spam-Score: -2.3 (--) +X-Spam-Report: SpamAssassin version 3.4.3 on bombadil.infradead.org summary: + Content analysis details: (-2.3 points) + pts rule name description + ---- ---------------------- + -------------------------------------------------- + 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) + [195.135.220.15 listed in wl.mailspike.net] + -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, + medium trust [195.135.220.15 listed in list.dnswl.org] + 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record + -0.0 SPF_PASS SPF: sender matches SPF record + 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders +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@i2se.com, devicetree@vger.kernel.org, f.fainelli@gmail.com, + linux-mmc@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, + linux-rpi-kernel@lists.infradead.org, phil@raspberrypi.com, + linux-arm-kernel@lists.infradead.org +Sender: "linux-arm-kernel" +Errors-To: + linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org + +The SD card power can be controlled trough a pin routed into the board's +external GPIO expander. Turn that into a regulator and provide it to +emmc2. + +Signed-off-by: Nicolas Saenz Julienne +--- + arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts +index b0ea8233b636..a2da058396fe 100644 +--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts ++++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts +@@ -55,6 +55,16 @@ sd_io_1v8_reg: sd_io_1v8_reg { + 3300000 0x0>; + status = "okay"; + }; ++ ++ sd_vcc_reg: sd_vcc_reg { ++ compatible = "regulator-fixed"; ++ regulator-name = "vcc-sd"; ++ regulator-min-microvolt = <3300000>; ++ regulator-max-microvolt = <3300000>; ++ regulator-boot-on; ++ enable-active-high; ++ gpio = <&expgpio 6 GPIO_ACTIVE_HIGH>; ++ }; + }; + + &firmware { +@@ -173,6 +183,7 @@ brcmf: wifi@1 { + /* EMMC2 is used to drive the SD card */ + &emmc2 { + vqmmc-supply = <&sd_io_1v8_reg>; ++ vmmc-supply = <&sd_vcc_reg>; + broken-cd; + status = "okay"; + }; diff --git a/arm-bcm2835-serial-8250_early-support-aux-uart.patch b/arm-bcm2835-serial-8250_early-support-aux-uart.patch new file mode 100644 index 000000000..5ab954996 --- /dev/null +++ b/arm-bcm2835-serial-8250_early-support-aux-uart.patch @@ -0,0 +1,47 @@ +From 57b76faf1d7860f070a1ee2d0b7eccd9f37ecc55 Mon Sep 17 00:00:00 2001 +From: Matthias Brugger +Date: Sun, 26 Jan 2020 13:33:14 +0100 +Subject: serial: 8250_early: Add earlycon for BCM2835 aux uart + +Define the OF early console for BCM2835 aux UART, which can be enabled +by passing "earlycon" on the boot command line. This UART is found on +BCM283x and BCM27xx SoCs, a.k.a. Raspberry Pi in its variants. + +Signed-off-by: Matthias Brugger +Link: https://lore.kernel.org/r/20200126123314.3558-1-matthias.bgg@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/8250/8250_bcm2835aux.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +diff --git a/drivers/tty/serial/8250/8250_bcm2835aux.c b/drivers/tty/serial/8250/8250_bcm2835aux.c +index e70e3cc30050..5cc03bf24f85 100644 +--- a/drivers/tty/serial/8250/8250_bcm2835aux.c ++++ b/drivers/tty/serial/8250/8250_bcm2835aux.c +@@ -137,6 +137,24 @@ static struct platform_driver bcm2835aux_serial_driver = { + }; + module_platform_driver(bcm2835aux_serial_driver); + ++#ifdef CONFIG_SERIAL_8250_CONSOLE ++ ++static int __init early_bcm2835aux_setup(struct earlycon_device *device, ++ const char *options) ++{ ++ if (!device->port.membase) ++ return -ENODEV; ++ ++ device->port.iotype = UPIO_MEM32; ++ device->port.regshift = 2; ++ ++ return early_serial8250_setup(device, NULL); ++} ++ ++OF_EARLYCON_DECLARE(bcm2835aux, "brcm,bcm2835-aux-uart", ++ early_bcm2835aux_setup); ++#endif ++ + MODULE_DESCRIPTION("BCM2835 auxiliar UART driver"); + MODULE_AUTHOR("Martin Sperl "); + MODULE_LICENSE("GPL v2"); +-- +cgit 1.2-0.3.lf.el7 diff --git a/kernel.spec b/kernel.spec index 281fc8849..5e9abbc58 100644 --- a/kernel.spec +++ b/kernel.spec @@ -828,8 +828,12 @@ Patch311: USB-pci-quirks-Add-Raspberry-Pi-4-quirk.patch Patch312: bcm2835-irqchip-Quiesce-IRQs-left-enabled-by-bootloader.patch # https://patchwork.kernel.org/patch/11420129/ Patch313: ARM-dts-bcm2711-Move-emmc2-into-its-own-bus.patch +# Upstream commit f87391eec2c5 thread: https://www.spinics.net/lists/linux-mmc/msg58036.html +Patch314: arm-bcm2711-mmc-sdhci-iproc-Add-custom-set_power-callback.patch # https://patchwork.freedesktop.org/patch/358980/ -Patch314: drm-vc4-Fix-HDMI-mode-validation.patch +Patch315: drm-vc4-Fix-HDMI-mode-validation.patch +# Upstream commit 57b76faf1d78 +Patch316: arm-bcm2835-serial-8250_early-support-aux-uart.patch # Tegra bits # https://www.spinics.net/lists/linux-tegra/msg48152.html @@ -2997,6 +3001,7 @@ fi %changelog * Fri Apr 3 2020 Peter Robinson - Raspberry Pi HDMI mode validation fix +- Raspberry Pi 4 rev 1.2 mmc fix * Thu Apr 02 2020 Jeremy Cline - 5.6.2-300 - Linux v5.6.2 -- cgit From 939ceca29c33a6227030b2fe405551247ccab197 Mon Sep 17 00:00:00 2001 From: "Justin M. Forbes" Date: Tue, 7 Apr 2020 08:37:17 -0500 Subject: Add patches to fix nouveau issues preventing booting the installer or system --- ...-workaround-runpm-fail-by-disabling-PCI-p.patch | 141 +++++++++++++++++++++ ...-gr-gp107-gp108-implement-workaround-for-.patch | 68 ++++++++++ kernel.spec | 9 ++ 3 files changed, 218 insertions(+) create mode 100644 0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch create mode 100644 0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch diff --git a/0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch b/0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch new file mode 100644 index 000000000..1511e4a7a --- /dev/null +++ b/0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch @@ -0,0 +1,141 @@ +From 7a7662fe09eb2ccd2eb93ce7261aa47c86111b4d Mon Sep 17 00:00:00 2001 +From: Karol Herbst +Date: Tue, 24 Mar 2020 21:29:23 +0100 +Subject: [PATCH 1/2] drm/nouveau: workaround runpm fail by disabling PCI power + management on certain intel bridges + +Fixes the infamous 'runtime PM' bug many users are facing on Laptops with +Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. + +Depending on the used kernel there might be messages like those in demsg: + +"nouveau 0000:01:00.0: Refused to change power state, currently in D3" +"nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config +space inaccessible)" +followed by backtraces of kernel crashes or timeouts within nouveau. + +It's still unkown why this issue exists, but this is a reliable workaround +and solves a very annoying issue for user having to choose between a +crashing kernel or higher power consumption of their Laptops. + +Signed-off-by: Karol Herbst +Cc: Bjorn Helgaas +Cc: Lyude Paul +Cc: Rafael J. Wysocki +Cc: Mika Westerberg +Cc: linux-pci@vger.kernel.org +Cc: linux-pm@vger.kernel.org +Cc: dri-devel@lists.freedesktop.org +Cc: nouveau@lists.freedesktop.org +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623 +Signed-off-by: Ben Skeggs +--- + drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++++++++++++++++++++++++++ + drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + + 2 files changed, 65 insertions(+) + +diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c +index 6b1629c14dd7..ca4087f5a15b 100644 +--- a/drivers/gpu/drm/nouveau/nouveau_drm.c ++++ b/drivers/gpu/drm/nouveau/nouveau_drm.c +@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev) + kfree(drm); + } + ++/* ++ * On some Intel PCIe bridge controllers doing a ++ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear. ++ * Skipping the intermediate D3hot step seems to make it work again. This is ++ * probably caused by not meeting the expectation the involved AML code has ++ * when the GPU is put into D3hot state before invoking it. ++ * ++ * This leads to various manifestations of this issue: ++ * - AML code execution to power on the GPU hits an infinite loop (as the ++ * code waits on device memory to change). ++ * - kernel crashes, as all PCI reads return -1, which most code isn't able ++ * to handle well enough. ++ * ++ * In all cases dmesg will contain at least one line like this: ++ * 'nouveau 0000:01:00.0: Refused to change power state, currently in D3' ++ * followed by a lot of nouveau timeouts. ++ * ++ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not ++ * documented PCI config space register 0x248 of the Intel PCIe bridge ++ * controller (0x1901) in order to change the state of the PCIe link between ++ * the PCIe port and the GPU. There are alternative code paths using other ++ * registers, which seem to work fine (executed pre Windows 8): ++ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved') ++ * - 0xb0 bit 0x10 (link disable) ++ * Changing the conditions inside the firmware by poking into the relevant ++ * addresses does resolve the issue, but it seemed to be ACPI private memory ++ * and not any device accessible memory at all, so there is no portable way of ++ * changing the conditions. ++ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared. ++ * ++ * The only systems where this behavior can be seen are hybrid graphics laptops ++ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether ++ * this issue only occurs in combination with listed Intel PCIe bridge ++ * controllers and the mentioned GPUs or other devices as well. ++ * ++ * documentation on the PCIe bridge controller can be found in the ++ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume 2" ++ * Section "12 PCI Express* Controller (x16) Registers" ++ */ ++ ++static void quirk_broken_nv_runpm(struct pci_dev *pdev) ++{ ++ struct drm_device *dev = pci_get_drvdata(pdev); ++ struct nouveau_drm *drm = nouveau_drm(dev); ++ struct pci_dev *bridge = pci_upstream_bridge(pdev); ++ ++ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL) ++ return; ++ ++ switch (bridge->device) { ++ case 0x1901: ++ drm->old_pm_cap = pdev->pm_cap; ++ pdev->pm_cap = 0; ++ NV_INFO(drm, "Disabling PCI power management to avoid bug\n"); ++ break; ++ } ++} ++ + static int nouveau_drm_probe(struct pci_dev *pdev, + const struct pci_device_id *pent) + { +@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev, + if (ret) + goto fail_drm_dev_init; + ++ quirk_broken_nv_runpm(pdev); + return 0; + + fail_drm_dev_init: +@@ -734,7 +793,11 @@ static void + nouveau_drm_remove(struct pci_dev *pdev) + { + struct drm_device *dev = pci_get_drvdata(pdev); ++ struct nouveau_drm *drm = nouveau_drm(dev); + ++ /* revert our workaround */ ++ if (drm->old_pm_cap) ++ pdev->pm_cap = drm->old_pm_cap; + nouveau_drm_device_remove(dev); + pci_disable_device(pdev); + } +diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h +index c2c332fbde97..2a6519737800 100644 +--- a/drivers/gpu/drm/nouveau/nouveau_drv.h ++++ b/drivers/gpu/drm/nouveau/nouveau_drv.h +@@ -140,6 +140,8 @@ struct nouveau_drm { + + struct list_head clients; + ++ u8 old_pm_cap; ++ + struct { + struct agp_bridge_data *bridge; + u32 base; +-- +2.25.1 + diff --git a/0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch b/0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch new file mode 100644 index 000000000..554800010 --- /dev/null +++ b/0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch @@ -0,0 +1,68 @@ +From 37b556606d1217b4367e622d88cef11c65764386 Mon Sep 17 00:00:00 2001 +From: Ben Skeggs +Date: Tue, 31 Mar 2020 16:08:44 +1000 +Subject: [PATCH 2/2] drm/nouveau/gr/gp107,gp108: implement workaround for HW + hanging during init + +Certain boards with GP107/GP108 chipsets hang (often, but randomly) for +unknown reasons during GR initialisation. + +The first tell-tale symptom of this issue is: + +nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ] + +appearing in dmesg, likely followed by many other failures being logged. + +Karol found this WAR for the issue a while back, but efforts to isolate +the root cause and proper fix have not yielded success so far. I've +modified the original patch to include a few more details, limit it to +GP107/GP108 by default, and added a config option to override this choice. + +Signed-off-by: Ben Skeggs +Reviewed-by: Karol Herbst +--- + .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 26 +++++++++++++++++++ + 1 file changed, 26 insertions(+) + +diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c +index dd8f85b8b3a7..f2f5636efac4 100644 +--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c +@@ -1981,8 +1981,34 @@ gf100_gr_init_(struct nvkm_gr *base) + { + struct gf100_gr *gr = gf100_gr(base); + struct nvkm_subdev *subdev = &base->engine.subdev; ++ struct nvkm_device *device = subdev->device; ++ bool reset = device->chipset == 0x137 || device->chipset == 0x138; + u32 ret; + ++ /* On certain GP107/GP108 boards, we trigger a weird issue where ++ * GR will stop responding to PRI accesses after we've asked the ++ * SEC2 RTOS to boot the GR falcons. This happens with far more ++ * frequency when cold-booting a board (ie. returning from D3). ++ * ++ * The root cause for this is not known and has proven difficult ++ * to isolate, with many avenues being dead-ends. ++ * ++ * A workaround was discovered by Karol, whereby putting GR into ++ * reset for an extended period right before initialisation ++ * prevents the problem from occuring. ++ * ++ * XXX: As RM does not require any such workaround, this is more ++ * of a hack than a true fix. ++ */ ++ reset = nvkm_boolopt(device->cfgopt, "NvGrResetWar", reset); ++ if (reset) { ++ nvkm_mask(device, 0x000200, 0x00001000, 0x00000000); ++ nvkm_rd32(device, 0x000200); ++ msleep(50); ++ nvkm_mask(device, 0x000200, 0x00001000, 0x00001000); ++ nvkm_rd32(device, 0x000200); ++ } ++ + nvkm_pmu_pgob(gr->base.engine.subdev.device->pmu, false); + + ret = nvkm_falcon_get(&gr->fecs.falcon, subdev); +-- +2.25.1 + diff --git a/kernel.spec b/kernel.spec index 5e9abbc58..5632562de 100644 --- a/kernel.spec +++ b/kernel.spec @@ -904,6 +904,12 @@ Patch511: e1000e-bump-up-timeout-to-wait-when-ME-un-configure-ULP-mode.patch # https://bugzilla.redhat.com/show_bug.cgi?id=1820196 Patch512: 0001-ALSA-hda-realtek-Add-quirk-for-Lenovo-Carbon-X1-8th-.patch +# nouveau runpm and secboot fixes +# Accepted nouveau upstream https://github.com/skeggsb/nouveau/commit/f5755e7069d4acbcce1a93692421f358241ead7b +Patch513: 0001-drm-nouveau-workaround-runpm-fail-by-disabling-PCI-p.patch +# Accepted nouveau upstream https://github.com/skeggsb/nouveau/commit/41c6a13e8143af71928749ea9895d2ebc2fb4ffd +Patch514: 0002-drm-nouveau-gr-gp107-gp108-implement-workaround-for-.patch + # END OF PATCH DEFINITIONS %endif @@ -2999,6 +3005,9 @@ fi # # %changelog +* Tue Apr 07 2020 Karol Herbst +- Add patches to fix nouveau issues preventing booting the installer or system + * Fri Apr 3 2020 Peter Robinson - Raspberry Pi HDMI mode validation fix - Raspberry Pi 4 rev 1.2 mmc fix -- cgit From 7c60344ea2ba58aab726859aa316533ae12a08bf Mon Sep 17 00:00:00 2001 From: Jeremy Cline Date: Tue, 7 Apr 2020 13:59:42 -0400 Subject: Bump the release --- kernel.spec | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel.spec b/kernel.spec index 5632562de..21e5fc11a 100644 --- a/kernel.spec +++ b/kernel.spec @@ -80,7 +80,7 @@ Summary: The Linux kernel # For non-released -rc kernels, this will be appended after the rcX and # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3" # -%global baserelease 300 +%global baserelease 301 %global fedora_build %{baserelease} # base_sublevel is the kernel version we're starting with and patching @@ -3005,7 +3005,7 @@ fi # # %changelog -* Tue Apr 07 2020 Karol Herbst +* Tue Apr 07 2020 Karol Herbst - 5.6.2-301 - Add patches to fix nouveau issues preventing booting the installer or system * Fri Apr 3 2020 Peter Robinson -- cgit