It reverts commit c745fe61 now that
Cayman is stable since VDDCI fix. Spread spectrum was not the culprit.

This depends on b0880e87
(drm/radeon/dpm: fix vddci setup typo on cayman).

Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to use the RREG32_SMC() accessor since the register
is an smc indirect index.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fixes hangs on driver load on some cards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76998



Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

If there are error flags in the aux transaction return
-EIO rather than -EBUSY.  -EIO restarts the whole transaction
while -EBUSY jus retries.  Fixes problematic aux transfers.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80684



Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Commit e8099177 ("dm mpath: push back requests instead of queueing")
modified multipath_busy() to return true if !pg_ready().  pg_ready()
checks the current state of the multipath device and may return false
even if a new IO is needed to change the state.

Bart Van Assche reported that he had multipath IO lockup when he was
performing cable pull tests.  Analysis showed that the multipath
device had a single path group with both paths active, but that the
path group itself was not active.  During the multipath device state
transitions 'queue_io' got set but nothing could clear it.  Clearing
'queue_io' only happens in __choose_pgpath(), but it won't be called
if multipath_busy() returns true due to pg_ready() returning false
when 'queue_io' is set.

As such the !pg_ready() check in multipath_busy() is wrong because new
IO will not be sent to multipath target and the multipath state change
won't happen.  That results in multipath IO lockup.

The intent of multipath_busy() is to avoid unnecessary cycles of
dequeue + request_fn + requeue if it is known that the multipath
device will requeue.

Such "busy" situations would be:
  - path group is being activated
  - there is no path and the multipath is setup to requeue if no path

Fix multipath_busy() to return "busy" early only for these specific
situations.

Reported-by: Bart Van Assche <bvanassche@acm.org>
Tested-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # v3.15

There's a race condition between the atomic_dec_and_test(&io->count)
in dec_count() and the waking of the sync_io() thread.  If the thread
is spuriously woken immediately after the decrement it may exit,
making the on stack io struct invalid, yet the dec_count could still
be using it.

Fix this race by using a completion in sync_io() and dec_count().

Reported-by: Minfei Huang <huangminfei@ucloud.cn>
Signed-off-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org

Signed-off-by: Jana Saout <jana@saout.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>

The commit 2c140a24 ("dm: allow remove to be deferred") introduced a
deferred removal feature for the device mapper.  When this feature is
used (by passing a flag DM_DEFERRED_REMOVE to DM_DEV_REMOVE_CMD ioctl)
and the user tries to remove a device that is currently in use, the
device will be removed automatically in the future when the last user
closes it.

Device mapper used the system workqueue to perform deferred removals.
However, some targets (dm-raid1, dm-mpath, dm-stripe) flush work items
scheduled for the system workqueue from their destructor.  If the
destructor itself is called from the system workqueue during deferred
removal, it introduces a possible deadlock - the workqueue tries to flush
itself.

Fix this possible deadlock by introducing a new workqueue for deferred
removals.  We allocate just one workqueue for all dm targets.  The
ability of dm targets to process IOs isn't dependent on deferred removal
of unused targets, so a deadlock due to shared workqueue isn't possible.

Also, cleanup local_init() to eliminate potential for returning success
on failure.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 3.13+

This patch fixes a memory leak that appears when caam_jr module is unloaded.

Cc: <stable@vger.kernel.org> # 3.13+
Signed-off-by: Cristian Stoica <cristian.stoica@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The soc_button_array PNP driver was introduced in 3.15.
But in commit eec15edb (ACPI / PNP: use device ID list for
PNPACPI device enumeration), when reworking the PNPACPI device
enumeration, we missed the soc_button_array device ID.

This results in a regression in 3.16-rc1 that soc_button_array
pnp device fails to be enumerated.

Fix the problem by adding soc_button_array device ID into the
acpi_pnp scan handler's ID list.

Fixes: eec15edb (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.

Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg

Ver3: moved SYS_RESTART check earlier, new name for pp_div.

Ver4: Minor issue changes

Ver5: Move registration of reboot notifier to edp_connector_init,
      Added warning comment to handler about lack of PM notification.

Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The console subsystem only provides a function to switch to a given
console, but we want to actually only switach away from vgacon.
Unconditionally switching to the dummy console resulted in switching
away from fbcon in multi-gpu setups when other gpu drivers are loaded
before i915.

Then either the reinitialization of fbcon when i915 registers its
fbdev emulation or the teardown of the fbcon driver killed the
machine. So only switch to the dummy console when it's required.

Kudos to Chris for the original idea, I've only refined it a bit to
still unregister vgacon even when it's currently unused.

This regression has been introduced in

commit a4de0526
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jun 5 16:20:46 2014 +0200

    drm/i915: Kick out vga console

Reported-and-tested-by: Ed Tomlinson <edt@aei.ca>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.

v2: Deal with gen4 36 bit physical address

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151


Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We should keep DEVICE_READY bit set in the ULPS enter sequence. In
exit sequence also we should set DEVICE_READY, but thats causing
blankout for me. Also exit sequence is simplified as per hw team
recommendation.

This should fix -
[drm:intel_dsi_clear_device_ready] *ERROR* DSI LP not going Low

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80818


Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

While sending DPI SHUTDOWN command, we cannot wait for FIFO empty as
pipes are not disabled at that time. In case of MIPI we disable port
first and send SHUTDOWN command while pipe is still running and FIFOs
will not be empty, causing spurious error log

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

The Toshiba CB35 Chromebook (with Celeron 2955U CPU) has a controllable
backlight although its VBT reports otherwise. Apply quirk to ignore the
backlight presence check during backlight setup.

Patch tested by author on Toshiba CB35.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813


Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
CC: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org # 3.15 only
[danvet: Add cc: stable because the regressing commit is in 3.15.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The Acer C720 and C720P Chromebooks (with Celeron 2955U CPU) have a
controllable backlight although their VBT reports otherwise. Apply quirk
to ignore the backlight presence check during backlight setup.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813


Tested-by: James Duley <jagduley@gmail.com>
Tested-by: Michael Mullin <masmullin@gmail.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
CC: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org # 3.15 only
[danvet: Add cc: stable because the regressing commit is in 3.15.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit c675949e
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Apr 9 11:31:37 2014 +0300

    drm/i915: do not setup backlight if not available according to VBT

caused a regression on machines with a misconfigured VBT. Add a quirk to
assert the presence of a controllable backlight. Use it to ignore the VBT
backlight presence check during backlight setup.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813


Tested-by: James Duley <jagduley@gmail.com>
Tested-by: Michael Mullin <masmullin@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org # 3.15 only
[danvet: Add cc: stable because the regressing commit is in 3.15.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Since commtit 8a7b1227 (cpufreq: davinci: move cpufreq driver to
drivers/cpufreq) this added dependancy only for CONFIG_ARCH_DAVINCI_DA850
where as davinci_cpufreq_init() call is used by all davinci platform.

This patch fixes following build error:

arch/arm/mach-davinci/built-in.o: In function `davinci_init_late':
:(.init.text+0x928): undefined reference to `davinci_cpufreq_init'
make: *** [vmlinux] Error 1

Fixes: 8a7b1227 (cpufreq: davinci: move cpufreq driver to drivers/cpufreq)
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch fixes the dma state machine lockup due to the processing
of IDENTIFY DEVICE PIO mode command. The X-Gene AHCI controller
has an errata in which it cannot clear the BSY bit after the PIO setup
FIS. The dma state machine enters CMFatalErrorUpdate state and locks
up. This patch also removes the dma restart workaround from the read_id
function as the read_id function is only called by libata layer for
ATA_INTERNAL commands. But for some cases eg: PORT MULTIPLIER
and udev, the framework will enumerate using SCSI commands and it will
not call read_id function.

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>

The subsequent patch will make use of them.

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The display in fdo#76483 pulses the hotplug line for link retraining
after we cut power to the main link on the source, even while it's
in D3.

fdo#76483

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Under some complicated circumstances (boot, suspend, resume, attach
second display, suspend, resume, suspend, detach second display,
resume, suspend, attach second display, resume), the fb_set_suspend()
call can somehow result in a modeset being attempted before we're
ready for it and things blow up in fun ways.

Running display init first fixes the issue.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

There's Apple machines out there which (probably completely arbitrarily)
restrict each output path to a particular head.  This causes us to not
be able to locate the output data needed to power on/off the DP output
correctly.

We fix this by passing in a head index we know is valid (as opposed to
"head 0").

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

When gcc 4.8 inlines this function, it eats up 16 bytes on the stack
every time. Eventually we hit warnings because our stack grew too
much:

ramnve0.c:1383:1: error: the frame size of 1496 bytes is larger than
1024 bytes

We fix this by preventing inlining for this function.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Fix backlight control for Acer TravelMate B113 Laptop by adding
it to the video_dmi_table.

A workaround before that was to use acpi_osi=Linux or
acpi_backlight=vendor on boot but even then, only the function-
keys worked.

With this change there is no need for boot parameters and DE's
controls work as well.

Signed-off-by: Martin Kepplinger <martink@posteo.de>
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

With win8 capabiltiy, the ACPI backlight control is broken.
The system also loses backlight setting when resuming from S3.

Add this model to the the ACPI video detect blacklist to make backlight
functionality work.

Although backlight functionality works via video.use_native_backlight=1,
this approach may be safer.

Signed-off-by: Edward Lin <yidi.lin@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Some Thinkpad laptops' firmware will initiate a backlight level change
request through operation region on the events of AC plug/unplug, but
since we are not using firmware's interface to do the backlight setting
on these affected laptops, we do not want the firmware to use some
arbitrary value from its ASL variable to set the backlight level on
AC plug/unplug either.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=76491
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77091


Reported-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Reported-and-tested-by: Anton Gubarkov <anton.gubarkov@gmail.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

It seems that some batteries (noticed on DELL JYPJ136) assume
capacity_now = design_capacity when fully charged. This causes
reported capacity to suddenly jump to >full_charge_capacity (and that
means capacity reported to userspace is >100% and incorrect)
values after 99%. This patch detects capacity_now > full_charge_capacity,
notifies userspace (unless it is the known bug where capacity_now ==
design_capacity) and trims the value to full_charge_capacity.

Signed-off-by: Josef Gajdusek <atx@atx.name>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The recently merged change (in v3.14-rc6) to ACPI resource detection
(below) causes all zero length ACPI resources to be elided from the
table:

  commit b355cee8
  Author: Zhang Rui <rui.zhang@intel.com>
  Date:   Thu Feb 27 11:37:15 2014 +0800

    ACPI / resources: ignore invalid ACPI device resources

This change has caused a regression in (at least) serial port detection
for a number of machines (see LP#1313981 [1]).  These seem to represent
their IO regions (presumably incorrectly) as a zero length region.
Reverting the above commit restores these serial devices.

Only elide zero length resources which lie at address 0.

Fixes: b355cee8 (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Writes into input registers doesn't make sense, even more so since
the writes actually ended up writing into the maximum limit registers.
Drop it.

Cc: stable@vger.kernel.org
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

It is customary to clamp limits instead of bailing out with an error
if a configured limit is out of the range supported by the driver.
This simplifies limit configuration, since the user will not typically
know chip and/or driver specific limits.

Reviewed-by: Jean Delvare <jdelvare@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

This device generates ABS_Z and ABS_RX events instead of ABS_X and
ABS_Y.

Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Upper limit for write operations to temperature limit registers
was clamped to a fractional value. However, limit registers do
not support fractional values. As a result, upper limits of 127.5
degrees C or higher resulted in a rounded limit of 128 degrees C.
Since limit registers are signed, this was stored as -128 degrees C.
Clamp limits to (-55, +127) degrees C to solve the problem.

Value on writes to auto_temp[12]_min and auto_temp[12]_max were not
clamped at all, but masked. As a result, out-of-range writes resulted
in a more or less arbitrary limit. Clamp those attributes to (0, 127)
degrees C for more predictable results.

Cc: Axel Lin <axel.lin@ingics.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581


Reported-and-tested-by: naszar <naszar@ya.ru>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Smatch detected two memory leaks on saved_ec:

drivers/acpi/ec.c:1070 acpi_ec_ecdt_probe() warn: possible
  memory leak of 'saved_ec'
drivers/acpi/ec.c:1109 acpi_ec_ecdt_probe() warn: possible
  memory leak of 'saved_ec'

Free saved_ec on these two error exit paths to stop the memory
leak.  Note that saved_ec maybe null, but kfree on null is allowed.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>