diff options
| -rw-r--r-- | drm-cma-reduce-dmesg-logs.patch | 53 | ||||
| -rw-r--r-- | kernel.spec | 8 | ||||
| -rw-r--r-- | sources | 3 | ||||
| -rw-r--r-- | tegra-Use-different-MSI-target-address-for-Tegra20.patch | 47 |
4 files changed, 6 insertions, 105 deletions
diff --git a/drm-cma-reduce-dmesg-logs.patch b/drm-cma-reduce-dmesg-logs.patch index 2e39d6e70..d7252c498 100644 --- a/drm-cma-reduce-dmesg-logs.patch +++ b/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); diff --git a/kernel.spec b/kernel.spec index f966d9ecd..e9e24393d 100644 --- a/kernel.spec +++ b/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. @@ -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-rc4-git4.xz) = 2f68128482824575c94e0282be64dd1490fa251b8806758c0d6ac2a7b3da8d9e0f098c0cd4ad07eaac280c4eb8331b898224acef641eea8fb3c2314b42114c0a +SHA512 (patch-4.14-rc5.xz) = 1b09fa9e2fae3b6ac172b2f130a84c9a1ea7c6ea89e0b799013814216dd0c5ba7eeae5b0abcd7dad289fd695abc5663b5fdd92cb7993729c52c08c538b73ace2 diff --git a/tegra-Use-different-MSI-target-address-for-Tegra20.patch b/tegra-Use-different-MSI-target-address-for-Tegra20.patch deleted file mode 100644 index 338693bcf..000000000 --- a/tegra-Use-different-MSI-target-address-for-Tegra20.patch +++ /dev/null @@ -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); |