Linux v4.14-rc5

drm-cma-reduce-dmesg-logs.patch

@@ -41,56 +41,3 @@ index 373e33f22be4..020e7668dfab 100644
  			size);
  		ret = -ENOMEM;
  		goto error;
-From patchwork Wed Oct  4 12:54:47 2017
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: cma: Take __GFP_NOWARN into account in cma_alloc()
-From: Boris Brezillon <boris.brezillon@free-electrons.com>
-X-Patchwork-Id: 180554
-Message-Id: <20171004125447.15195-1-boris.brezillon@free-electrons.com>
-To: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
- Laura Abbott <labbott@redhat.com>
-Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
- Jaewon Kim <jaewon31.kim@samsung.com>, dri-devel@lists.freedesktop.org
-Date: Wed,  4 Oct 2017 14:54:47 +0200
-
-cma_alloc() unconditionally prints an INFO message when the CMA
-allocation fails. Make this message conditional on the non-presence of
-__GFP_NOWARN in gfp_mask.
-
-Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
-Acked-by: Laura Abbott <labbott@redhat.com>
----
-Hello,
-
-This patch aims at removing INFO messages that are displayed when the
-VC4 driver tries to allocate buffer objects. From the driver perspective
-an allocation failure is acceptable, and the driver can possibly do
-something to make following allocation succeed (like flushing the VC4
-internal cache).
-
-Also, I don't understand why this message is only an INFO message, and
-not a WARN (pr_warn()). Please let me know if you have good reasons to
-keep it as an unconditional pr_info().
-
-Thanks,
-
-Boris
----
- mm/cma.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/mm/cma.c b/mm/cma.c
-index c0da318c020e..022e52bd8370 100644
---- a/mm/cma.c
-+++ b/mm/cma.c
-@@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
- 
- 	trace_cma_alloc(pfn, page, count, align);
- 
--	if (ret) {
-+	if (ret && !(gfp_mask & __GFP_NOWARN)) {
- 		pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
- 			__func__, count, ret);
- 		cma_debug_show_areas(cma);

kernel.spec

@@ -67,9 +67,9 @@ Summary: The Linux kernel
 # The next upstream release sublevel (base_sublevel+1)
 %define upstream_sublevel %(echo $((%{base_sublevel} + 1)))
 # The rc snapshot level
-%global rcrev 4
+%global rcrev 5
 # The git snapshot level
-%define gitrev 4
+%define gitrev 0
 # Set rpm version accordingly
 %define rpmversion 4.%{upstream_sublevel}.0
 %endif
@@ -599,7 +599,6 @@ Patch305: arm-imx6-hummingboard2.patch
 Patch306: arm64-Add-option-of-13-for-FORCE_MAX_ZONEORDER.patch
 
 # https://patchwork.kernel.org/patch/9967397/
-Patch307: tegra-Use-different-MSI-target-address-for-Tegra20.patch
 
 # https://patchwork.kernel.org/patch/9815555/
 # https://patchwork.kernel.org/patch/9815651/
@@ -2214,6 +2213,9 @@ fi
 #
 #
 %changelog
+* Mon Oct 16 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.14.0-0.rc5.git0.1
+- Linux v4.14-rc5
+
 * Mon Oct 16 2017 Justin M. Forbes <jforbes@fedoraproject.org>
 - Disable debugging options.
 

sources

@@ -1,4 +1,3 @@
 SHA512 (linux-4.13.tar.xz) = a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2
 SHA512 (perf-man-4.13.tar.gz) = 9bcc2cd8e56ec583ed2d8e0b0c88e7a94035a1915e40b3177bb02d6c0f10ddd4df9b097b1f5af59efc624226b613e240ddba8ddc2156f3682f992d5455fc5c03
-SHA512 (patch-4.14-rc4.xz) = 11edc0714c9b7ff34986d1534c490987f5977940afc5b176a424a23e437d572d83f8d689b4505128371bf6d4c5956a2042c9c4d222eb72363b977b69c819b3e3
+SHA512 (patch-4.14-rc5.xz) = 1b09fa9e2fae3b6ac172b2f130a84c9a1ea7c6ea89e0b799013814216dd0c5ba7eeae5b0abcd7dad289fd695abc5663b5fdd92cb7993729c52c08c538b73ace2
-SHA512 (patch-4.14-rc4-git4.xz) = 2f68128482824575c94e0282be64dd1490fa251b8806758c0d6ac2a7b3da8d9e0f098c0cd4ad07eaac280c4eb8331b898224acef641eea8fb3c2314b42114c0a

tegra-Use-different-MSI-target-address-for-Tegra20.patch

@@ -1,47 +0,0 @@
-From patchwork Sat Sep 23 06:17:40 2017
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: PCI: tegra: Use different MSI target address for Tegra20
-From: Thierry Reding <thierry.reding@gmail.com>
-X-Patchwork-Id: 9967397
-Message-Id: <20170923061740.6012-1-treding@nvidia.com>
-To: Bjorn Helgaas <bhelgaas@google.com>
-Cc: Thierry Reding <thierry.reding@gmail.com>,
- Jonathan Hunter <jonathanh@nvidia.com>,
- linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org
-Date: Fri, 22 Sep 2017 23:17:40 -0700
-
-The Tegra20 PCIe controller has a different address range for MSI, so
-select a different target address.
-
-Fixes: d7bd554f27c9 ("PCI: tegra: Do not allocate MSI target memory")
-Signed-off-by: Thierry Reding <treding@nvidia.com>
----
- drivers/pci/host/pci-tegra.c | 12 +++++++++++-
- 1 file changed, 11 insertions(+), 1 deletion(-)
-
-diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
-index e8e1ddbaabc9..5b02ea59524b 100644
---- a/drivers/pci/host/pci-tegra.c
-+++ b/drivers/pci/host/pci-tegra.c
-@@ -1563,8 +1563,18 @@ static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
- 	 * none of the Tegra SoCs that contain this PCI host bridge can
- 	 * address more than 16 GiB of system memory, the last 4 KiB of
- 	 * these 1012 GiB is a good candidate.
-+	 *
-+	 * Unfortunately, Tegra20 is slightly different in that the physical
-+	 * address for this MSI region is limited to the lower 32 bits of the
-+	 * address map, so the address that we pick is going to have to be
-+	 * located somewhere within the region addressable by the CPU and
-+	 * on-SoC controllers. To be on the safe side, we select an address
-+	 * from a region that is marked unused (0xf0010000 - 0xfffeffff).
- 	 */
--	msi->phys = 0xfcfffff000;
-+	if (soc->msi_base_shift > 0)
-+		msi->phys = 0xfcfffff000;
-+	else
-+		msi->phys = 0x00f0010000;
- 
- 	afi_writel(pcie, msi->phys >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
- 	afi_writel(pcie, msi->phys, AFI_MSI_AXI_BAR_ST);