merge origin

6 files changed, 715 insertions, 1 deletions

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 <kherbst@redhat.com>
+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 <kherbst@redhat.com>
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Lyude Paul <lyude@redhat.com>
+Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
+Cc: Mika Westerberg <mika.westerberg@intel.com>
+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 <bskeggs@redhat.com>
+---
+ 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 <bskeggs@redhat.com>
+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 <bskeggs@redhat.com>
+Reviewed-by: Karol Herbst <kherbst@redhat.com>
+---
+ .../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/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 <nsaenzjulienne@suse.de>
+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 <nsaenzjulienne@suse.de>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/20200306174413.20634-2-nsaenzjulienne@suse.de
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+---
+ 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 <nsaenzjulienne@suse.de>
+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 <nsaenzjulienne@suse.de>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/20200306174413.20634-10-nsaenzjulienne@suse.de
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+---
+ 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 <nsaenzjulienne@suse.de>
+X-Patchwork-Id: 11424593
+Return-Path: 
+ <SRS0=iJpk=4X=lists.infradead.org=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@kernel.org>
+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 <patchwork-linux-arm@patchwork.kernel.org>;
+ 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 <patchwork-linux-arm@patchwork.kernel.org>;
+ 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 <nsaenzjulienne@suse.de>
+To: adrian.hunter@intel.com, linux-kernel@vger.kernel.org,
+ Rob Herring <robh+dt@kernel.org>,
+ Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+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: <linux-arm-kernel.lists.infradead.org>
+List-Unsubscribe: 
+ <http://lists.infradead.org/mailman/options/linux-arm-kernel>,
+ <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe>
+List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
+List-Post: <mailto:linux-arm-kernel@lists.infradead.org>
+List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>
+List-Subscribe: 
+ <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>,
+ <mailto:linux-arm-kernel-request@lists.infradead.org?subject=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" <linux-arm-kernel-bounces@lists.infradead.org>
+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 <nsaenzjulienne@suse.de>
+---
+ 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 <nsaenzjulienne@suse.de>
+X-Patchwork-Id: 11424599
+Return-Path: 
+ <SRS0=iJpk=4X=lists.infradead.org=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@kernel.org>
+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 <patchwork-linux-arm@patchwork.kernel.org>;
+ 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 <patchwork-linux-arm@patchwork.kernel.org>;
+ 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 <nsaenzjulienne@suse.de>
+To: adrian.hunter@intel.com, linux-kernel@vger.kernel.org,
+ Rob Herring <robh+dt@kernel.org>,
+ Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+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: <linux-arm-kernel.lists.infradead.org>
+List-Unsubscribe: 
+ <http://lists.infradead.org/mailman/options/linux-arm-kernel>,
+ <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe>
+List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
+List-Post: <mailto:linux-arm-kernel@lists.infradead.org>
+List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>
+List-Subscribe: 
+ <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>,
+ <mailto:linux-arm-kernel-request@lists.infradead.org?subject=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" <linux-arm-kernel-bounces@lists.infradead.org>
+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 <nsaenzjulienne@suse.de>
+---
+ 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 <mbrugger@suse.com>
+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 <mbrugger@suse.com>
+Link: https://lore.kernel.org/r/20200126123314.3558-1-matthias.bgg@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <kernel@martin.sperl.org>");
+ MODULE_LICENSE("GPL v2");
+-- 
+cgit 1.2-0.3.lf.el7
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 <nsaenzjulienne@suse.de>
+X-Patchwork-Id: 358980
+Message-Id: <20200326122001.22215-1-nsaenzjulienne@suse.de>
+To: Eric Anholt <eric@anholt.net>,
+	Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Stefan Wahren <stefan.wahren@i2se.com>, f.fainelli@gmail.com,
+ Dave Stevenson <dave.stevenson@raspberrypi.com>,
+ David Airlie <airlied@linux.ie>, linux-kernel@vger.kernel.org,
+ dri-devel@lists.freedesktop.org, maxime@cerno.tech,
+ Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
+ 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 <stefan.wahren@i2se.com>
+Suggested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
+Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+Reviewed-by: Maxime Ripard <mripard@kernel.org>
+---
+ 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 a74235046..1b1ff5cbd 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -82,7 +82,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 350
+%global baserelease 301
 %global fedora_build %{baserelease}
 
 # base_sublevel is the kernel version we're starting with and patching
@@ -846,6 +846,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/
+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
@@ -916,6 +922,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
@@ -3014,6 +3026,13 @@ fi
 #
 #
 %changelog
+* Tue Apr 07 2020 Karol Herbst <kherbst@redhat.com> - 5.6.2-301
+- Add patches to fix nouveau issues preventing booting the installer or system
+
+* Fri Apr  3 2020 Peter Robinson <pbrobinson@fedoraproject.org>
+- Raspberry Pi HDMI mode validation fix
+- Raspberry Pi 4 rev 1.2 mmc fix
+
 * Thu Apr 02 2020 Jeremy Cline <jcline@redhat.com> - 5.6.2-300
 - Linux v5.6.2