UBUNTU: Start new release

Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: [Packaging] supply perf with appropriate prefix to ensure use of local config

If we do not supply an installation prefix when we are building perf
it will assume it is designed to run relative to the builders HOME.
This means that as built on a buildd we will check for the system
configuration relative to the buildd users home rather than in /etc.
This implies a local user could use this to compromise other users _if_
there is a buildd user installed on the system and they have access to it.

CVE-2013-1060
BugLink: http://bugs.launchpad.net/bugs/1206200
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: (no-up) Revert "UBUNTU: SAUCE: (no-up) drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight"

This reverts commit 2b42ac5a76c845f073d7bbdc5075fe5c801db11f.
This reverts commit 9742db3291cd95e7d524f10e41f913737fcb3333.

The two reverted commits are to be replaced by
"9f5b330 drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight"
from v3.8.13.6.

Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Steve Conklin <sconklin@canonical.com>
xen/blkback: Check device permissions before allowing OP_DISCARD

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 upstream.

We need to make sure that the device is not RO or that
the request is not past the number of sectors we want to
issue the DISCARD operation for.

This fixes CVE-2013-2140.

Acked-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
[v1: Made it pr_warn instead of pr_debug]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRL

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 016fcab8ff46fca29375d484226ec91932aa4a07 upstream.

According to the sgtl5000 reference manual, the default value of CHIP_SSS_CTRL
is 0x10.

Reported-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 5c78dfe87ea04b501ee000a7f03b9432ac9d008c upstream.

SGTL5000_PLL_FRAC_DIV_MASK is used to mask bits 0-10 (11 bits in total) of
register CHIP_PLL_CTRL, so fix the mask to accomodate all this bit range.

Reported-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 067556084a0e412013af6b0250a3143ae5afde6d upstream.

obj->mm_list link to dev_priv->mm.inactive_list/active_list
obj->global_list link to dev_priv->mm.unbound_list/bound_list

This regression has been introduced in

commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jan 10 18:03:00 2013 +0100

    drm/i915: Revert shrinker changes from "Track unbound pages"

Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
[danvet: Add regression notice.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[ kamal: backport to 3.8 ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a

BugLink: http://bugs.launchpad.net/bugs/1207977

commit aaf8a5167291b65e9116cb8736d862965b57c13a upstream.

It's not a good idea to also run the pipe_control cleanup.

This regression has been introduced whith the original cs tlb w/a in

commit b45305fce5bb1abec263fcff9d81ebecd6306ede
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Dec 17 16:21:27 2012 +0100

    drm/i915: Implement workaround for broken CS tlb on i830/845

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"

BugLink: http://bugs.launchpad.net/bugs/1207977

commit c11e5f35ab490bd30591563816fbc83526521777 upstream.

This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for
IvyBridge CPUs.

The original commit results in repeated 'Timed out waiting for forcewake old
ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
with i7-3770K CPU. It ultimately results in a hangup if the system is highly
loaded. Reverting the commit for IvyBridge CPUs fixes the issue.

Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
this condition can result in secondary issues.

v2: Only revert patch for Ivybridge CPUs
    Issue info message if mt forcewake is disabled on Ivybridge

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: Fix write-read race with multiple rings

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 upstream.

Daniel noticed a problem where is we wrote to an object with ring A in
the middle of a very long running batch, then executed a quick batch on
ring B before a batch that reads from the same object, its obj->ring would
now point to ring B, but its last_write_seqno would be still relative to
ring A. This would allow for the user to read from the object before the
GPU had completed the write, as set_domain would only check that ring B
had passed the last_write_seqno.

To fix this simply (and inelegantly), we bump the last_write_seqno when
switching rings so that the last_write_seqno is always relative to the
current obj->ring.

This fixes igt/tests/gem_write_read_ring_switch.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Add note about the newly created igt which exercises this
bug.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: merge {i965, sandybridge}_write_fence_reg()

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 56c844e539f1f6f5768c5f73f119e6f4aed9d320 upstream.

The two functions are rather similar, so merge them.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[ kamal: 3.8.y-stable prereq for d18b9619 ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: Fix incoherence with fence updates on Sandybridge+

BugLink: http://bugs.launchpad.net/bugs/1207977

commit d18b9619034230b6f945e215276425636ca401fe upstream.

This hopefully fixes the root cause behind the workaround added in

commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Apr 4 21:31:03 2013 +0100

    drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

Thanks to further investigation by Jon Bloomfield, he realised that
the 64-bit register might be broken up by the hardware into two 32-bit
writes (a problem we have encountered elsewhere). This non-atomicity
would then cause an issue where a second thread would see an
intermediate register state (new high dword, old low dword), and this
register would randomly be used in preference to its own thread register.
This would cause the second thread to read from and write into a fairly
random tiled location.  Breaking the operation into 3 explicit 32-bit
updates (first disable the fence, poke the upper bits, then poke the lower
bits and enable) ensures that, given proper serialisation between the
32-bit register write and the memory transfer, that the fence value is
always consistent.

Armed with this knowledge, we can explain how the previous workaround
work. The key to the corruption is that a second thread sees an
erroneous fence register that conflicts and overrides its own. By
serialising the fence update across all CPUs, we have a small window
where no GTT access is occurring and so hide the potential corruption.
This also leads to the conclusion that the earlier workaround was
incomplete.

v2: Be overly paranoid about the order in which fence updates become
visible to the GPU to make really sure that we turn the fence off before
doing the update, and then only switch the fence on afterwards.

Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs"

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 46a0b638f35b45fc13d3dc0deb6a7e17988170b2 upstream.

This reverts commit 25ff119 and the follow on for Valleyview commit 2dc8aae.

commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Apr 4 21:31:03 2013 +0100

    drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

commit 2dc8aae06d53458dd3624dc0accd4f81100ee631
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 22 17:08:06 2013 +0100

    drm/i915: Workaround incoherence with fence updates on Valleyview

Jon Bloomfield came up with a plausible explanation and cheap fix
(drm/i915: Fix incoherence with fence updates on Sandybridge+) for the
race condition, so lets run with it.

This is a candidate for stable as the old workaround incurs a
significant cost (calling wbinvd on all CPUs before performing the
register write) for some workloads as noted by Carsten Emde.

Link: http://lists.freedesktop.org/archives/intel-gfx/2013-June/028819.html
References: https://www.osadl.org/?id=1543#c7602
References: https://bugs.freedesktop.org/show_bug.cgi?id=63825
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[ kamal: revert the 3.8.y-stable version of 25ff119:
  This reverts commit b578b3a82d830e2170d403b1fb29b649e26a48fb. ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: rename sdvox_reg to hdmi_reg on HDMI context

BugLink: http://bugs.launchpad.net/bugs/1207977

commit b242b7f745650832f445dca3e19efc3dd2d65a66 upstream.

Some (but not all) of the HDMI registers can be used to control sDVO,
so those registers have two names. IMHO, when we're talking about
HDMI, we really should call the HDMI control register "hdmi_reg"
instead of "sdvox_reg", otherwise we'll just confuse people reading
our code (we now have platforms with HDMI but without SDVO). So now
"struct intel_hdmi" has a member called "hdmi_reg" instead of
"sdvox_reg".

Also, don't worry: "struct intel_sdvo" still has a member called
"sdvo_reg".

v2: Rebase (v1 was sent in May 2012).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[ kamal: backport to 3.8.y-stable as prereq for:
  bcf53de4 "drm/i915: Preserve the DDI_A_4_LANES bit from the bios" ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: don't setup hdmi for port D edp in ddi_init

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026 upstream.

dp_init_connector adjusts the encoder type if it is a eDP panel. Use
that to decide whether we should set up a hdmi connector or not.

To do so reorder the hdmi connector setup sequence in ddi_init a bit.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[ kamal: 3.8.y-stable prereq for:
  bcf53de4 "drm/i915: Preserve the DDI_A_4_LANES bit from the bios" ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/i915: Preserve the DDI_A_4_LANES bit from the bios

BugLink: http://bugs.launchpad.net/bugs/1207977

commit bcf53de4e60d9000b82f541d654529e2902a4c2c upstream.

Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes
on eDP. This fixes eDP on hsw with > 2 lanes.

Also s/port_reversal/saved_port_bits/ since the current name is
confusing.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/radeon/hdmi: make sure we have an afmt block assigned

BugLink: http://bugs.launchpad.net/bugs/1207977

commit c2b4cacfe9816c1fe378c785ce8a678cf0635ec6 upstream.

Prevents a segfault if an afmt block is not assigned to the
encoder such as in the LVDS or eDP case.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66714

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[ kamal: backport to 3.8 (context) ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/radeon: allocate SA bo in the requested domain

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 7220f639c2eca36774dbf65b16fe503bfb40fff5 upstream.

This avoid moving the BO directly after allocating it.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[ kamal: 3.8.y-stable prereq for:
  6c4f978 "drm/radeon: allow selection of alignment in the sub-allocator" ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
drm/radeon: allow selection of alignment in the sub-allocator

BugLink: http://bugs.launchpad.net/bugs/1207977

commit 6c4f978b357bc779c703fda1f200e9179623d3e9 upstream.

There are cases where we need more than 4k alignment.  No
functional change with this commit.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
ACPI / memhotplug: Fix a stale pointer in error path

BugLink: http://bugs.launchpad.net/bugs/1207977

commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.

device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().

The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory.  A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Steve Conklin <sconklin@canonical.com>