--- /dev/null
+From c898261c0dad617f0f1080bedc02d507a2fcfb92 Mon Sep 17 00:00:00 2001
+From: Keith Packard <keithp@keithp.com>
+Date: Wed, 25 Jan 2012 08:16:25 -0800
+Subject: drm/i915: Force explicit bpp selection for intel_dp_link_required
+
+From: Keith Packard <keithp@keithp.com>
+
+commit c898261c0dad617f0f1080bedc02d507a2fcfb92 upstream.
+
+It is never correct to use intel_crtc->bpp in intel_dp_link_required,
+so instead pass an explicit bpp in to this function. This patch
+only supports 18bpp and 24bpp modes, which means that 10bpc modes will
+be computed incorrectly. Fixing that will require more extensive
+changes, and so must be addressed separately from this bugfix.
+
+intel_dp_link_required is called from intel_dp_mode_valid and
+intel_dp_mode_fixup.
+
+* intel_dp_mode_valid is called to list supported modes; in this case,
+ the current crtc values cannot be relevant as the modes in question
+ may never be selected. Thus, using intel_crtc->bpp is never right.
+
+* intel_dp_mode_fixup is called during mode setting, but it is run
+ well before ironlake_crtc_mode_set is called to set intel_crtc->bpp,
+ so using intel_crtc-bpp in this path can only ever get a stale
+ value.
+
+Cc: Lubos Kolouch <lubos.kolouch@gmail.com>
+Cc: Adam Jackson <ajax@redhat.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881
+Tested-by: Dave Airlie <airlied@redhat.com>
+Tested-by: camalot@picnicpark.org (Dell Latitude 6510)
+Tested-by: Roland Dreier <roland@digitalvampire.org>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_dp.c | 20 +++++---------------
+ 1 file changed, 5 insertions(+), 15 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -208,17 +208,8 @@ intel_dp_link_clock(uint8_t link_bw)
+ */
+
+ static int
+-intel_dp_link_required(struct intel_dp *intel_dp, int pixel_clock, int check_bpp)
++intel_dp_link_required(int pixel_clock, int bpp)
+ {
+- struct drm_crtc *crtc = intel_dp->base.base.crtc;
+- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+- int bpp = 24;
+-
+- if (check_bpp)
+- bpp = check_bpp;
+- else if (intel_crtc)
+- bpp = intel_crtc->bpp;
+-
+ return (pixel_clock * bpp + 9) / 10;
+ }
+
+@@ -245,12 +236,11 @@ intel_dp_mode_valid(struct drm_connector
+ return MODE_PANEL;
+ }
+
+- mode_rate = intel_dp_link_required(intel_dp, mode->clock, 0);
++ mode_rate = intel_dp_link_required(mode->clock, 24);
+ max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
+
+ if (mode_rate > max_rate) {
+- mode_rate = intel_dp_link_required(intel_dp,
+- mode->clock, 18);
++ mode_rate = intel_dp_link_required(mode->clock, 18);
+ if (mode_rate > max_rate)
+ return MODE_CLOCK_HIGH;
+ else
+@@ -683,7 +673,7 @@ intel_dp_mode_fixup(struct drm_encoder *
+ int lane_count, clock;
+ int max_lane_count = intel_dp_max_lane_count(intel_dp);
+ int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 : 0;
+- int bpp = mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 0;
++ int bpp = mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
+ static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
+
+ if (is_edp(intel_dp) && intel_dp->panel_fixed_mode) {
+@@ -701,7 +691,7 @@ intel_dp_mode_fixup(struct drm_encoder *
+ for (clock = 0; clock <= max_clock; clock++) {
+ int link_avail = intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
+
+- if (intel_dp_link_required(intel_dp, mode->clock, bpp)
++ if (intel_dp_link_required(mode->clock, bpp)
+ <= link_avail) {
+ intel_dp->link_bw = bws[clock];
+ intel_dp->lane_count = lane_count;
--- /dev/null
+From e57b6886f555ab57f40a01713304e2053efe51ec Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Wed, 8 Feb 2012 16:42:52 +0100
+Subject: drm/i915: no lvds quirk for AOpen MP45
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit e57b6886f555ab57f40a01713304e2053efe51ec upstream.
+
+According to a bug report, it doesn't have one.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263
+Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Keith Packard <keithp@keithp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_lvds.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/i915/intel_lvds.c
++++ b/drivers/gpu/drm/i915/intel_lvds.c
+@@ -694,6 +694,14 @@ static const struct dmi_system_id intel_
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
++ .ident = "AOpen i45GMx-I",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "AOpen"),
++ DMI_MATCH(DMI_BOARD_NAME, "i45GMx-I"),
++ },
++ },
++ {
++ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Aopen i945GTt-VFA",
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_VERSION, "AO00001JW"),
--- /dev/null
+From 0629292117572a60465f38cdedde2f8164c3df0b Mon Sep 17 00:00:00 2001
+From: Greg Rose <gregory.v.rose@intel.com>
+Date: Thu, 2 Feb 2012 23:51:43 +0000
+Subject: igb: fix vf lookup
+
+From: Greg Rose <gregory.v.rose@intel.com>
+
+commit 0629292117572a60465f38cdedde2f8164c3df0b upstream.
+
+Recent addition of code to find already allocated VFs failed to take
+account that systems with 2 or more multi-port SR-IOV capable controllers
+might have already enabled VFs. Make sure that the VFs the function is
+finding are actually subordinate to the particular instance of the adapter
+that is looking for them and not subordinate to some device that has
+previously enabled SR-IOV.
+
+This is applicable to 3.2+ kernels.
+
+Reported-by: David Ahern <daahern@cisco.com>
+Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
+Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/igb/igb_main.c
++++ b/drivers/net/ethernet/intel/igb/igb_main.c
+@@ -4965,7 +4965,8 @@ static int igb_find_enabled_vfs(struct i
+ vf_devfn = pdev->devfn + 0x80;
+ pvfdev = pci_get_device(hw->vendor_id, device_id, NULL);
+ while (pvfdev) {
+- if (pvfdev->devfn == vf_devfn)
++ if (pvfdev->devfn == vf_devfn &&
++ (pvfdev->bus->number >= pdev->bus->number))
+ vfs_found++;
+ vf_devfn += vf_stride;
+ pvfdev = pci_get_device(hw->vendor_id,
--- /dev/null
+From a4b08329c74985e5cc3a44b6d2b2c59444ed8079 Mon Sep 17 00:00:00 2001
+From: Greg Rose <gregory.v.rose@intel.com>
+Date: Fri, 3 Feb 2012 00:54:13 +0000
+Subject: ixgbe: fix vf lookup
+
+From: Greg Rose <gregory.v.rose@intel.com>
+
+commit a4b08329c74985e5cc3a44b6d2b2c59444ed8079 upstream.
+
+Recent addition of code to find already allocated VFs failed to take
+account that systems with 2 or more multi-port SR-IOV capable controllers
+might have already enabled VFs. Make sure that the VFs the function is
+finding are actually subordinate to the particular instance of the adapter
+that is looking for them and not subordinate to some device that has
+previously enabled SR-IOV.
+
+This bug exists in 3.2 stable as well as 3.3 release candidates.
+
+Reported-by: David Ahern <daahern@cisco.com>
+Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
+Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
++++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+@@ -67,7 +67,8 @@ static int ixgbe_find_enabled_vfs(struct
+ vf_devfn = pdev->devfn + 0x80;
+ pvfdev = pci_get_device(IXGBE_INTEL_VENDOR_ID, device_id, NULL);
+ while (pvfdev) {
+- if (pvfdev->devfn == vf_devfn)
++ if (pvfdev->devfn == vf_devfn &&
++ (pvfdev->bus->number >= pdev->bus->number))
+ vfs_found++;
+ vf_devfn += 2;
+ pvfdev = pci_get_device(IXGBE_INTEL_VENDOR_ID,
--- /dev/null
+From a4a03fc7ef89020baca4f19174e6a43767c6d78a Mon Sep 17 00:00:00 2001
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+Date: Fri, 3 Feb 2012 22:31:13 +0530
+Subject: perf evsel: Fix an issue where perf report fails to show the proper percentage
+
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+
+commit a4a03fc7ef89020baca4f19174e6a43767c6d78a upstream.
+
+This patch fixes an issue where perf report shows nan% for certain
+perf.data files. The below is from a report for a do_fork probe:
+
+ -nan% sshd [kernel.kallsyms] [k] do_fork
+ -nan% packagekitd [kernel.kallsyms] [k] do_fork
+ -nan% dbus-daemon [kernel.kallsyms] [k] do_fork
+ -nan% bash [kernel.kallsyms] [k] do_fork
+
+A git bisect shows commit f3bda2c as the cause. However, looking back
+through the git history, I saw commit 640c03c which seems to have
+removed the required initialization for perf_sample->period. The problem
+only started showing after commit f3bda2c. The below patch re-introduces
+the initialization and it fixes the problem for me.
+
+With the below patch, for the same perf.data:
+
+ 73.08% bash [kernel.kallsyms] [k] do_fork
+ 8.97% 11-dhclient [kernel.kallsyms] [k] do_fork
+ 6.41% sshd [kernel.kallsyms] [k] do_fork
+ 3.85% 20-chrony [kernel.kallsyms] [k] do_fork
+ 2.56% sendmail [kernel.kallsyms] [k] do_fork
+
+This patch applies over current linux-tip commit 9949284.
+
+Problem introduced in:
+
+$ git describe 640c03c
+v2.6.37-rc3-83-g640c03c
+
+Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: Robert Richter <robert.richter@amd.com>
+Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
+Link: http://lkml.kernel.org/r/20120203170113.5190.25558.stgit@localhost6.localdomain6
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/evsel.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/tools/perf/util/evsel.c
++++ b/tools/perf/util/evsel.c
+@@ -390,6 +390,7 @@ int perf_event__parse_sample(const union
+
+ data->cpu = data->pid = data->tid = -1;
+ data->stream_id = data->id = data->time = -1ULL;
++ data->period = 1;
+
+ if (event->header.type != PERF_RECORD_SAMPLE) {
+ if (!sample_id_all)
--- /dev/null
+From 7a0153ee15575a4d07b5da8c96b79e0b0fd41a12 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@redhat.com>
+Date: Mon, 6 Feb 2012 18:54:06 -0200
+Subject: perf tools: Fix perf stack to non executable on x86_64
+
+From: Jiri Olsa <jolsa@redhat.com>
+
+commit 7a0153ee15575a4d07b5da8c96b79e0b0fd41a12 upstream.
+
+By adding following objects:
+ bench/mem-memcpy-x86-64-asm.o
+the x86_64 perf binary ended up with executable stack.
+
+The reason was that above object are assembler sourced and is missing the
+GNU-stack note section. In such case the linker assumes that the final binary
+should not be restricted at all and mark the stack as RWX.
+
+Adding section ".note.GNU-stack" definition to mentioned object, with all
+flags disabled, thus omiting this object from linker stack flags decision.
+
+Problem introduced in:
+
+ $ git describe ea7872b
+ v2.6.37-rc2-19-gea7872b
+
+Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570
+Reported-by: Clark Williams <williams@redhat.com>
+Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
+Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com
+Signed-off-by: Jiri Olsa <jolsa@redhat.com>
+[ committer note: Backported fix to perf/urgent (3.3-rc2+) ]
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/bench/mem-memcpy-x86-64-asm.S | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/tools/perf/bench/mem-memcpy-x86-64-asm.S
++++ b/tools/perf/bench/mem-memcpy-x86-64-asm.S
+@@ -1,2 +1,8 @@
+
+ #include "../../../arch/x86/lib/memcpy_64.S"
++/*
++ * We need to provide note.GNU-stack section, saying that we want
++ * NOT executable stack. Otherwise the final linking will assume that
++ * the ELF stack should not be restricted at all and set it RWX.
++ */
++.section .note.GNU-stack,"",@progbits
--- /dev/null
+ixgbe-fix-vf-lookup.patch
+igb-fix-vf-lookup.patch
+perf-evsel-fix-an-issue-where-perf-report-fails-to-show-the-proper-percentage.patch
+perf-tools-fix-perf-stack-to-non-executable-on-x86_64.patch
+drm-i915-force-explicit-bpp-selection-for-intel_dp_link_required.patch
+drm-i915-no-lvds-quirk-for-aopen-mp45.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
