--- /dev/null
+From ebc0bad4a05ad63979e8bc115cea3b8abdf814c7 Mon Sep 17 00:00:00 2001
+From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+Date: Wed, 19 Jun 2013 03:14:20 +0200
+Subject: drm/prime: Honor requested file flags when exporting a buffer
+
+From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+
+commit ebc0bad4a05ad63979e8bc115cea3b8abdf814c7 upstream.
+
+The DRM PRIME API passes file flags to the driver for the exported
+buffer. Honor them instead of hardcoding 0600.
+
+Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_prime.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/drm_prime.c
++++ b/drivers/gpu/drm/drm_prime.c
+@@ -190,8 +190,7 @@ struct dma_buf *drm_gem_prime_export(str
+ if (ret)
+ return ERR_PTR(ret);
+ }
+- return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
+- 0600);
++ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags);
+ }
+ EXPORT_SYMBOL(drm_gem_prime_export);
+
--- /dev/null
+From 3813f5ca9ab7a00e80a17aab34f155453c66c78a Mon Sep 17 00:00:00 2001
+From: Jerome Glisse <jglisse@redhat.com>
+Date: Thu, 6 Jun 2013 12:41:17 -0400
+Subject: drm/radeon: do not try to uselessly update virtual memory pagetable
+
+From: Jerome Glisse <jglisse@redhat.com>
+
+commit 3813f5ca9ab7a00e80a17aab34f155453c66c78a upstream.
+
+If a buffer is never bound to a virtual memory pagetable than don't try
+to unbind it. Only drawback is that we don't update the pagetable when
+unbinding the ib pool buffer which is fine because it only happens at
+suspend or module unload/shutdown.
+
+Fixes spurious messages about buffers without VM mappings. E.g.:
+radeon 0000:01:00.0: bo ffff88020afac400 don't has a mapping in vm ffff88021ca2b900
+
+Signed-off-by: Jerome Glisse <jglisse@redhat.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_gart.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/radeon/radeon_gart.c
++++ b/drivers/gpu/drm/radeon/radeon_gart.c
+@@ -1197,11 +1197,13 @@ int radeon_vm_bo_update_pte(struct radeo
+ int radeon_vm_bo_rmv(struct radeon_device *rdev,
+ struct radeon_bo_va *bo_va)
+ {
+- int r;
++ int r = 0;
+
+ mutex_lock(&rdev->vm_manager.lock);
+ mutex_lock(&bo_va->vm->mutex);
+- r = radeon_vm_bo_update_pte(rdev, bo_va->vm, bo_va->bo, NULL);
++ if (bo_va->soffset) {
++ r = radeon_vm_bo_update_pte(rdev, bo_va->vm, bo_va->bo, NULL);
++ }
+ mutex_unlock(&rdev->vm_manager.lock);
+ list_del(&bo_va->vm_list);
+ mutex_unlock(&bo_va->vm->mutex);
--- /dev/null
+From 8444d5c69549aa0f0b574cc608742d4669e1cc01 Mon Sep 17 00:00:00 2001
+From: Jerome Glisse <jglisse@redhat.com>
+Date: Wed, 19 Jun 2013 10:02:28 -0400
+Subject: drm/radeon: update lockup tracking when scheduling in empty ring
+
+From: Jerome Glisse <jglisse@redhat.com>
+
+commit 8444d5c69549aa0f0b574cc608742d4669e1cc01 upstream.
+
+There might be issue with lockup detection when scheduling on an
+empty ring that have been sitting idle for a while. Thus update
+the lockup tracking data when scheduling new work in an empty ring.
+
+Signed-off-by: Jerome Glisse <jglisse@redhat.com>
+Tested-by: Andy Lutomirski <luto@amacapital.net>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_ring.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_ring.c
++++ b/drivers/gpu/drm/radeon/radeon_ring.c
+@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_devi
+ return -ENOMEM;
+ /* Align requested size with padding so unlock_commit can
+ * pad safely */
++ radeon_ring_free_size(rdev, ring);
++ if (ring->ring_free_dw == (ring->ring_size / 4)) {
++ /* This is an empty ring update lockup info to avoid
++ * false positive.
++ */
++ radeon_ring_lockup_update(ring);
++ }
+ ndw = (ndw + ring->align_mask) & ~ring->align_mask;
+ while (ndw > (ring->ring_free_dw - 1)) {
+ radeon_ring_free_size(rdev, ring);
--- /dev/null
+From 0541881502a1276149889fe468662ff6a8fc8f6d Mon Sep 17 00:00:00 2001
+From: Yinghai Lu <yinghai@kernel.org>
+Date: Thu, 13 Jun 2013 13:17:02 -0700
+Subject: range: Do not add new blank slot with add_range_with_merge
+
+From: Yinghai Lu <yinghai@kernel.org>
+
+commit 0541881502a1276149889fe468662ff6a8fc8f6d upstream.
+
+Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
+during add range) broke mtrr cleanup on his setup in 3.9.5.
+corresponding commit in upstream is fbe06b7bae7c.
+
+The reason is add_range_with_merge could generate blank spot.
+
+We could avoid that by searching new expanded start/end, that
+new range should include all connected ranges in range array.
+At last add the new expanded start/end to the range array.
+Also move up left array so do not add new blank slot in the
+range array.
+
+-v2: move left array to avoid enhance add_range()
+-v3: include fix from Joshua about memmove declaring when
+ DYN_DEBUG is used.
+
+Reported-by: Joshua Covington <joshuacov@googlemail.com>
+Tested-by: Joshua Covington <joshuacov@googlemail.com>
+Signed-off-by: Yinghai Lu <yinghai@kernel.org>
+Link: http://lkml.kernel.org/r/1371154622-8929-3-git-send-email-yinghai@kernel.org
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/range.c | 23 ++++++++++++-----------
+ 1 file changed, 12 insertions(+), 11 deletions(-)
+
+--- a/kernel/range.c
++++ b/kernel/range.c
+@@ -4,7 +4,7 @@
+ #include <linux/kernel.h>
+ #include <linux/init.h>
+ #include <linux/sort.h>
+-
++#include <linux/string.h>
+ #include <linux/range.h>
+
+ int add_range(struct range *range, int az, int nr_range, u64 start, u64 end)
+@@ -32,9 +32,8 @@ int add_range_with_merge(struct range *r
+ if (start >= end)
+ return nr_range;
+
+- /* Try to merge it with old one: */
++ /* get new start/end: */
+ for (i = 0; i < nr_range; i++) {
+- u64 final_start, final_end;
+ u64 common_start, common_end;
+
+ if (!range[i].end)
+@@ -45,14 +44,16 @@ int add_range_with_merge(struct range *r
+ if (common_start > common_end)
+ continue;
+
+- final_start = min(range[i].start, start);
+- final_end = max(range[i].end, end);
+-
+- /* clear it and add it back for further merge */
+- range[i].start = 0;
+- range[i].end = 0;
+- return add_range_with_merge(range, az, nr_range,
+- final_start, final_end);
++ /* new start/end, will add it back at last */
++ start = min(range[i].start, start);
++ end = max(range[i].end, end);
++
++ memmove(&range[i], &range[i + 1],
++ (nr_range - (i + 1)) * sizeof(range[i]));
++ range[nr_range - 1].start = 0;
++ range[nr_range - 1].end = 0;
++ nr_range--;
++ i--;
+ }
+
+ /* Need to add it: */
acpi-resources-call-acpi_get_override_irq-only-for-legacy-irq-resources.patch
acpi-dock-take-acpi-scan-lock-in-write_undock.patch
acpi-pm-fix-error-code-path-for-power-resources.patch
+drm-prime-honor-requested-file-flags-when-exporting-a-buffer.patch
+drm-radeon-do-not-try-to-uselessly-update-virtual-memory-pagetable.patch
+drm-radeon-update-lockup-tracking-when-scheduling-in-empty-ring.patch
+range-do-not-add-new-blank-slot-with-add_range_with_merge.patch
+x86-mtrr-fix-original-mtrr-range-get-for-mtrr_cleanup.patch
+x86-fix-build-error-and-kconfig-for-ia32_emulation-and-binfmt.patch
+x86-fix-section-mismatch-on-load_ucode_ap.patch
--- /dev/null
+From d1603990ea626668c78527376d9ec084d634202d Mon Sep 17 00:00:00 2001
+From: Randy Dunlap <rdunlap@infradead.org>
+Date: Tue, 18 Jun 2013 12:33:40 -0700
+Subject: x86: fix build error and kconfig for ia32_emulation and binfmt
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+commit d1603990ea626668c78527376d9ec084d634202d upstream.
+
+Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF
+when COMPAT_BINFMT_ELF is being selected.
+
+warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)
+
+fs/built-in.o: In function `elf_core_dump':
+compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs'
+compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size'
+compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs'
+compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data'
+
+[ hpa: This was sent to me for -next but it is a low risk build fix ]
+
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -2268,6 +2268,7 @@ source "fs/Kconfig.binfmt"
+ config IA32_EMULATION
+ bool "IA32 Emulation"
+ depends on X86_64
++ select BINFMT_ELF
+ select COMPAT_BINFMT_ELF
+ select HAVE_UID16
+ ---help---
--- /dev/null
+From 949785996ec2250fa958fc3a924e5186e9a8fa2c Mon Sep 17 00:00:00 2001
+From: Paul Gortmaker <paul.gortmaker@windriver.com>
+Date: Wed, 19 Jun 2013 11:15:26 -0400
+Subject: x86: Fix section mismatch on load_ucode_ap
+
+From: Paul Gortmaker <paul.gortmaker@windriver.com>
+
+commit 949785996ec2250fa958fc3a924e5186e9a8fa2c upstream.
+
+We are in the process of removing all the __cpuinit annotations.
+While working on making that change, an existing problem was
+made evident:
+
+ WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
+ in reference from the function cpu_init() to the function
+ .init.text:load_ucode_ap() The function cpu_init() references
+ the function __init load_ucode_ap(). This is often because cpu_init
+ lacks a __init annotation or the annotation of load_ucode_ap is wrong.
+
+This now appears because in my working tree, cpu_init() is no longer
+tagged as __cpuinit, and so the audit picks up the mismatch. The 2nd
+hypothesis from the audit is the correct one, as there was an incorrect
+__init tag on the prototype in the header (but __cpuinit was used on
+the function itself.)
+
+The audit is telling us that the prototype's __init annotation took
+effect and the function did land in the .init.text section. Checking
+with objdump on a mainline tree that still has __cpuinit shows that
+the __cpuinit on the function takes precedence over the __init on the
+prototype, but that won't be true once we make __cpuinit a no-op.
+
+Even though we are removing __cpuinit, we temporarily align both
+the function and the prototype on __cpuinit so that the changeset
+can be applied to stable trees if desired.
+
+[ hpa: build fix only, no object code change ]
+
+Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.com
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/microcode.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/include/asm/microcode.h
++++ b/arch/x86/include/asm/microcode.h
+@@ -60,11 +60,11 @@ static inline void __exit exit_amd_micro
+ #ifdef CONFIG_MICROCODE_EARLY
+ #define MAX_UCODE_COUNT 128
+ extern void __init load_ucode_bsp(void);
+-extern __init void load_ucode_ap(void);
++extern void __cpuinit load_ucode_ap(void);
+ extern int __init save_microcode_in_initrd(void);
+ #else
+ static inline void __init load_ucode_bsp(void) {}
+-static inline __init void load_ucode_ap(void) {}
++static inline void __cpuinit load_ucode_ap(void) {}
+ static inline int __init save_microcode_in_initrd(void)
+ {
+ return 0;
--- /dev/null
+From d8d386c10630d8f7837700f4c466443d49e12cc0 Mon Sep 17 00:00:00 2001
+From: Yinghai Lu <yinghai@kernel.org>
+Date: Thu, 13 Jun 2013 13:17:01 -0700
+Subject: x86, mtrr: Fix original mtrr range get for mtrr_cleanup
+
+From: Yinghai Lu <yinghai@kernel.org>
+
+commit d8d386c10630d8f7837700f4c466443d49e12cc0 upstream.
+
+Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
+during add range) broke mtrr cleanup on his setup in 3.9.5.
+corresponding commit in upstream is fbe06b7bae7c.
+
+ *BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G
+
+https://bugzilla.kernel.org/show_bug.cgi?id=59491
+
+So it rejects new var mtrr layout.
+
+It turns out we have some problem with initial mtrr range retrieval.
+The current sequence is:
+ x86_get_mtrr_mem_range
+ ==> bunchs of add_range_with_merge
+ ==> bunchs of subract_range
+ ==> clean_sort_range
+ add_range_with_merge for [0,1M)
+ sort_range()
+
+add_range_with_merge could have blank slots, so we can not just
+sort only, that will have final result have extra blank slot in head.
+
+So move that calling add_range_with_merge for [0,1M), with that we
+could avoid extra clean_sort_range calling.
+
+Reported-by: Joshua Covington <joshuacov@googlemail.com>
+Tested-by: Joshua Covington <joshuacov@googlemail.com>
+Signed-off-by: Yinghai Lu <yinghai@kernel.org>
+Link: http://lkml.kernel.org/r/1371154622-8929-2-git-send-email-yinghai@kernel.org
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/mtrr/cleanup.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
++++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
+@@ -714,15 +714,15 @@ int __init mtrr_cleanup(unsigned address
+ if (mtrr_tom2)
+ x_remove_size = (mtrr_tom2 >> PAGE_SHIFT) - x_remove_base;
+
+- nr_range = x86_get_mtrr_mem_range(range, 0, x_remove_base, x_remove_size);
+ /*
+ * [0, 1M) should always be covered by var mtrr with WB
+ * and fixed mtrrs should take effect before var mtrr for it:
+ */
+- nr_range = add_range_with_merge(range, RANGE_NUM, nr_range, 0,
++ nr_range = add_range_with_merge(range, RANGE_NUM, 0, 0,
+ 1ULL<<(20 - PAGE_SHIFT));
+- /* Sort the ranges: */
+- sort_range(range, nr_range);
++ /* add from var mtrr at last */
++ nr_range = x86_get_mtrr_mem_range(range, nr_range,
++ x_remove_base, x_remove_size);
+
+ range_sums = sum_ranges(range, nr_range);
+ printk(KERN_INFO "total RAM covered: %ldM\n",
projects / thirdparty / kernel / stable-queue.git / commitdiff
