This patch adds lib/idr.c based transport_init_session_tags() logic
that allows fabric drivers to setup a per-cpu se_sess->sess_tag_pool
and associated se_sess->sess_cmd_map for basic tagged pre-allocation
of fabric descriptor sized memory.

v5 changes:
  - Convert to percpu_ida.h include

v4 changes:
  - Add transport_alloc_session_tags() for fabrics that need early
    transport_init_session()

v3 changes:
  - Update to percpu-ida usage

Cc: Kent Overstreet <kmo@daterainc.com>
Cc: Asias He <asias@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: NAsias He <asias@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch updates iser-target code to support login negotiation
multi-plexing.  This includes only using isert_conn->conn_login_comp
for the first login request PDU, pushing the subsequent processing
to iscsi_conn->login_work -> iscsi_target_do_login_rx(), and turning
isert_get_login_rx() into a NOP.

v3 changes:
   - Drop unnecessary LOGIN_FLAGS_READ_ACTIVE bit set in
     isert_rx_login_req()
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

There is no need for iscsi_target_do_login_io() anymore in modern code,
so go ahead and call iscsi_target_do_tx_login_io() directly within
iscsi_target_do_login().
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch adds a sock->sk_state_change() -> iscsi_target_sk_state_change()
callback in order to handle transient TCP failures during the login process,
where sock->sk_data_ready() -> iscsi_target_sk_data_ready() may not be
called to release connection resources, and relinquish tpg->np_login_lock
via iscsit_deaccess_np()

It performs the sk->sk_state check using iscsi_target_sk_state_check() to
look for TCP_CLOSE_WAIT + TCP_CLOSE, and invokes schedule_delayed_work() ->
iscsi_target_do_cleanup() to perform the remaining cleanup from process
context.

It adds an explicit sk_state_check to iscsi_target_do_login() in order
to determine a state failure when iscsi_target_sk_state_change() may
not be able to proceed before LOGIN_FLAGS_READY=1 is set.

Also use sk->sk_sndtimeo -> sk->sk_rcvtimeo settings during login to
iscsi_target_set_sock_callbacks(), and revert back post login to use
MAX_SCHEDULE_TIMEOUT in iscsi_target_restore_sock_callbacks().
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch adds support for login negotiation multi-plexing in
iscsi-target code.

This involves handling the first login request PDU + payload and
login response PDU + payload within __iscsi_target_login_thread()
process context, and then changing struct sock->sk_data_ready()
so that all subsequent exchanges are handled by workqueue process
context, to allow other incoming login requests to be received
in parallel by __iscsi_target_login_thread().

Upon login negotiation completion (or failure), ->sk_data_ready()
is replaced with the original kernel sockets handler saved in
iscsi_conn->orig_data_ready.

v3 changes:
  - Convert iscsi_target_sk_data_ready() lock access to
    write[lock,unlock]_bh()
  - Only clear LOGIN_FLAGS_READ_ACTIVE when iscsi_target_do_login()
    returns zero
  - Add LOGIN_FLAGS_READY + LOGIN_FLAGS_CLOSED bit checks to
    iscsi_target_sk_data_ready()
  - Make INIT_DELAYED_WORK() + iscsi_target_set_sock_callbacks() setup
    happen earlier by moving from iscsi_target_start_negotiation() into
    iscsi_target_locate_portal()
  - Set LOGIN_FLAGS_READY bit in iscsi_target_start_negotiation()
    after iscsi_target_do_login() returns zero.

v2 changes:
  - Add login_timer in iscsi_target_do_login_rx() to avoid
    possible endless sleep with MSG_WAITALL for traditional
    iscsi-target in certain network configurations.
  - Convert lprintk() -> pr_debug()
  - Remove forward declarations of iscsi_target_set_sock_callbacks(),
    iscsi_target_restore_sock_callbacks() and iscsi_target_sk_data_ready()
  - Make iscsi_target_set_sock_callbacks + iscsi_target_restore_sock_callbacks()
    static (Fengguang)
  - Make iscsi_target_do_login_rx() safe for iser-target w/o conn->sock
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch prepares the iscsi-target login code for multi-plexing
support.  This includes:

 - Adding iscsi_tpg_np->tpg_np_kref + iscsit_login_kref_put() for
   handling callback of iscsi_tpg_np->tpg_np_comp
 - Adding kref_put() in iscsit_deaccess_np()
 - Adding kref_put() and wait_for_completion() in
   iscsit_reset_np_thread()
 - Refactor login failure path release logic into
   iscsi_target_login_sess_out()
 - Update __iscsi_target_login_thread() to handle
   iscsi_post_login_handler() asynchronous completion
 - Add shutdown parameter for iscsit_clear_tpg_np_login_thread*()

v3 changes:
 - Convert iscsi_portal_group->np_login_lock to ->np_login_sem
 - Add LOGIN_FLAGS definitions

v2 changes:
 - Remove duplicate call to iscsi_post_login_handler() in
   __iscsi_target_login_thread()
 - Drop unused iscsi_np->np_login_tpg
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Odd little issue, found that if you create an IPv6 portal bound to the
IN6ADDR_ANY wildcard address it will accept IPv4 connections (as long as
bindv6only isn't set globally) but respond to SendTargets requests with
an IPv4-mapped IPv6 address.

Example over loopback:

 In targetcli create a wildcard IPv6 portal
   /iscsi/iqn.../portals/> create ::
 Which should create a portal [::]:3260

 Initiate SendTargets discovery to the portal using an IPv4 address
   # iscsiadm -m discovery -t st -p 127.0.0.1
 The response formats TargetAddress as [::ffff:127.0.0.1]:3260,1

This still works and uses v4 on the network between two v6 sockets, but
only if the initiator supports IPv6 with v4-mapped addresses.

This change detects v4-mapped address on v6 sockets for the wildcard
case, and instead formats the TargetAddress response as an IPv4 address.

In order to not further complicate iscsit_build_sendtargets_response,
I've actually simplified it by moving the bracket wrapping of IPv6
address into iscsit_accept_np where local_ip and login_ip strings are
set.  That also simplifies iscsi_stat_tgt_attr_show_attr_fail_intr_addr.

Side effect of the string format change is that
lio_target_nacl_show_info will now print login_ip bracket wrapped for
IPv6 connections, as will a few debug prints.
Signed-off-by: NChris Leech <cleech@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Changing this attribute to 0 will mean that all initiators that login
to the target while the target has generate_node_acls=1 will see all
TPG LUNs, which may be the desired behavior in some cases.

(nab: Apply patch without macro changes)
Reported-by: NCraig Watson <craig.watson@vanguard-rugged.com>
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

The usage of strict_strtoul() and strict_strtoull() is not preferred,
because strict_strtoul() and strict_strtoull() are obsolete. Thus,
kstrtoul() and kstrtoull() should be used.

v2: Fix incorrect return in ft_add_tpg (Fengguang)
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This reverts commit 407a2c2a.

Explanation provided by Benjamin Tissoires:

Commit "HID: hid-logitech-dj, querying_devices was never set" activate
a flag which guarantees that we do not ask the receiver for too many
enumeration. When the flag is set, each following enumeration call is
discarded (the usb request is not forwarded to the receiver). The flag
is then released when the driver receive a pairing information event,
which normally follows the enumeration request.
However, the USB3 bug makes the driver think the enumeration request
has been forwarded to the receiver. However, it is actually not the
case because the USB stack returns -EPIPE. So, when a new unknown
device appears, the workaround consisting in asking for a new
enumeration is not working anymore: this new enumeration is discarded
because of the flag, which is never reset.

A solution could be to trigger a timeout before releasing it, but for
now, let's just revert the patch.
Reported-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Tested-by: NSune Mølgaard <sune@molgaard.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In adt7470_write_word_data(), which writes two bytes using
i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed
together when they should be OR-ed together.

The return code of i2c_smbus_write_byte_data() is zero for success.

The upshot is only the first byte was ever written to the hardware.
The 2nd byte was never written out.

I noticed that trying to set the fan speed limits was not working
correctly on my system.  Setting the fan speed limits is the only
code that uses adt7470_write_word_data().  After making the change
the limit settings work and the alarms work also.
Signed-off-by: NCurt Brune <curt@cumulusnetworks.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

It takes an unsigned value. This happens not to blow up on 64-bit
architectures, but it does on 32-bit, causing
drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
timestamps for vblank events. Which in turn causes e.g. gnome-shell to
hang after a DPMS off cycle with current xf86-video-ati Git.

[airlied: regression introduced in drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos]

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59836Tested-by: Nshui yangwei <yangweix.shui@intel.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The smc ucode is required for dpm (dynamic power
management), but if it's missing just skip dpm setup
and don't disable acceleration.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=67876Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The rlc is required for dpm to work properly, so if
the rlc ucode is missing, don't enable dpm.  Enabling
dpm without the rlc enabled can result in hangs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We need proper locking in the driver when accessing instanced
registers on CIK.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We don't pin the BO on allocation, so don't unpin it on free.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Improve error handling in case userspace sends us
an invalid command buffer.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We also need to check the handle.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Otherwise just reinitialize from scratch on resume,
and so make it more likely to succeed.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For r6xx+ asics.  This mirrors the behavior of pre-r6xx
asics.  We need to program the MC even if something
else in startup() fails.  Failure to do so results in
an unusable GPU.

Based on a fix from: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to set the wallclock ratio and adjust the phase
and module registers appropriately.  May fix problems
with audio timing at certain display timings.

v2: properly handle clocks below 24mhz
v3: rebase r600 changes
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Enabling spread spectrum on the engine clock
leads to hangs on some asics.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66963Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Removing the clock/power or resetting the VCPU can cause
hangs if that happens in the middle of a register write.

Stall the memory and register bus before putting the VCPU
into reset. Keep it in reset when unloading the module or
suspending.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There are some hardware issue with reclocking on SI when
UVD is active, so use a stable power state when UVD is
active.  Fixes possible hangs and performance issues when
using UVD on SI.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to check for engine and memory clock ss separately
and only enable dynamic ss if either of them are found.

This should fix systems which have a ss table, but do
not have entries for engine or memory.  On those systems
we may enable dynamic spread spectrum without enabling
it on the engine or memory clocks which can lead to a
hang in some cases.

fixes some systems reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=66963

v2: fix typo
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

On rv770 and newer, clock gating is not required
for thermal protection.  The only requirement is that
the design utilizes a thermal sensor.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There are two audio dtos on radeon asics that you can
select between.  Normally, dto0 is used for hdmi and
dto1 for DP, but it seems that the dto is somehow
tied to the encoders on DCE3 asics.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=67435Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

When we reset the GPU, we need to properly tear
down power management before reseting the GPU and then
set it back up again after reset.  Add the missing
radeon_pm_[suspend|resume] calls to the gpu reset
function.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In theory, under a given ACPI namespace node there should be only
one child device object with _ADR whose value matches a given bus
address exactly.  In practice, however, there are systems in which
multiple child device objects under a given parent have _ADR matching
exactly the same address.  In those cases we use _STA to determine
which of the multiple matching devices is enabled, since some systems
are known to indicate which ACPI device object to associate with the
given physical (usually PCI) device this way.

Unfortunately, as it turns out, there are systems in which many
device objects under the same parent have _ADR matching exactly the
same bus address and none of them has _STA, in which case they all
should be regarded as enabled according to the spec.  Still, if
those device objects are supposed to represent bridges (e.g. this
is the case for device objects corresponding to PCIe ports), we can
try harder and skip the ones that have no child device objects in the
ACPI namespace.  With luck, we can avoid using device objects that we
are not expected to use this way.

Although this only works for bridges whose children also have ACPI
namespace representation, it is sufficient to address graphics
adapter detection issues on some systems, so rework the code finding
a matching device ACPI handle for a given bus address to implement
this idea.

Introduce a new function, acpi_find_child(), taking three arguments:
the ACPI handle of the device's parent, a bus address suitable for
the device's bus type and a bool indicating if the device is a
bridge and make it work as outlined above.  Reimplement the function
currently used for this purpose, acpi_get_child(), as a call to
acpi_find_child() with the last argument set to 'false' and make
the PCI subsystem use acpi_find_child() with the bridge information
passed as the last argument to it.  [Lan Tianyu notices that it is
not sufficient to use pci_is_bridge() for that, because the device's
subordinate pointer hasn't been set yet at this point, so use
hdr_type instead.]

This change fixes a regression introduced inadvertently by commit
33f767d7 (ACPI: Rework acpi_get_child() to be more efficient) which
overlooked the fact that for acpi_walk_namespace() "post-order" means
"after all children have been visited" rather than "on the way back",
so for device objects without children and for namespace walks of
depth 1, as in the acpi_get_child() case, the "post-order" callbacks
ordering is actually the same as the ordering of "pre-order" ones.
Since that commit changed the namespace walk in acpi_get_child() to
terminate after finding the first matching object instead of going
through all of them and returning the last one, it effectively
changed the result returned by that function in some rare cases and
that led to problems (the switch from a "pre-order" to a "post-order"
callback was supposed to prevent that from happening, but it was
ineffective).

As it turns out, the systems where the change made by commit
33f767d7 actually matters are those where there are multiple ACPI
device objects representing the same PCIe port (which effectively
is a bridge).  Moreover, only one of them, and the one we are
expected to use, has child device objects in the ACPI namespace,
so the regression can be addressed as described above.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60561Reported-by: NPeter Wu <lekensteyn@gmail.com>
Tested-by: NVladimir Lalov <mail@vlalov.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+

This sysfs file was called ignore_nice_load earlier and commit
4d5dcc42 (cpufreq: governor: Implement per policy instances of
governors) changed its name to ignore_nice by mistake.

Lets get it renamed back to its original name.
Reported-by: NMartin von Gagern <Martin.vGagern@gmx.net>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 42913c79 (MIPS: Loongson2: Use clk API instead of direct
dereferences) broke the cpufreq functionality on Loongson2 boards:
clk_set_rate() is called before the CPU frequency table is
initialized, and therefore will always fail.

Fix by moving the clk_set_rate() after the table initialization.
Tested on Lemote FuLoong mini-PC.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

try_offline_node() checks that all CPUs associated with the given
node have been removed by using cpu_present_bits.  If all cpus
related to that node have been removed, try_offline_node() clears
the node information.

However, try_offline_node() called from acpi_processor_remove() never
clears the node information.  For disabling cpu_present_bits,
acpi_unmap_lsapic() needs be called.  Yet, acpi_unmap_lsapic() is
called after try_offline_node() has run.  So when try_offline_node()
runs, the CPU's cpu_present_bits is always set.

Fix the issue by moving try_offline_node() after acpi_unmap_lsapic().

The problem fixed here was uncovered by commit cecdb193 "ACPI / scan:
Change the implementation of acpi_bus_trim()".

[rjw: Changelog]
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On muxed systems, the other vgaswitcheroo client may depend on i915 to
handle the backlight. We began switching off the backlight since

commit a261b246
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 26 19:21:47 2012 +0200

    drm/i915: disable all crtcs at suspend time

breaking backlight on discreet graphics in (some) muxed systems.

Keep the backlight on when the state is changed through vgaswitcheroo.

Note: The alternative would be to add a quirk table to achieve the same
based on system identifiers, but AFAICS it would asymptotically approach
effectively the same as this patch as more IDs are added, but with the
maintenance burden of the quirk table.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55311Tested-by: NFede <fedevx@yahoo.com>
Tested-by: NAximab <laurent.debian@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59785Tested-by: Nsfievet <sebastien.fievet@free.fr>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The SDVO code tries to compare the encoder's and crtc's idea of the
pixel_multiplier. Normally they have to match, but when transitioning
to DPMS off, we turn off the pipe before reading out the pipe_config,
so the pixel_multiplier in the pipe_config will be 0, whereas the
encoder will still have its pixel_multiplier set to whatever value we
were using when the display was active. This leads to a warning
from intel_modeset_check_state().

WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378 intel_sdvo_get_config+0x158/0x160()
SDVO pixel multiplier mismatch, port: 0, encoder: 1
Modules linked in: snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep
CPU: 1 PID: 2846 Comm: Xorg Not tainted 3.11.0-rc3-00208-gbe1e8d7-dirty #19
Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS  MM11.88Z.0055.B03.0604071521 04/07/06
 00000000 00000000 ef0afa54 c1597bbb c1737ea4 ef0afa84 c10392ca c1737e6c
 ef0afab0 00000b1e c1737ea4 00000562 c12dfbe8 c12dfbe8 ef0afb14 00000000
 f697ec00 ef0afa9c c103936e 00000009 ef0afa94 c1737e6c ef0afab0 ef0afadc
Call Trace:
 [<c1597bbb>] dump_stack+0x41/0x56
 [<c10392ca>] warn_slowpath_common+0x7a/0xa0
 [<c103936e>] warn_slowpath_fmt+0x2e/0x30
 [<c12dfbe8>] intel_sdvo_get_config+0x158/0x160
 [<c12c3220>] check_crtc_state+0x1e0/0xb10
 [<c12cdc7d>] intel_modeset_check_state+0x29d/0x7c0
 [<c12dfe5c>] intel_sdvo_dpms+0x5c/0xa0
 [<c12985de>] drm_mode_obj_set_property_ioctl+0x40e/0x420
 [<c1298625>] drm_mode_connector_property_set_ioctl+0x35/0x40
 [<c1289294>] drm_ioctl+0x3e4/0x540
 [<c10fc1a2>] do_vfs_ioctl+0x72/0x570
 [<c10fc72f>] SyS_ioctl+0x8f/0xa0
 [<c159b7fa>] sysenter_do_call+0x12/0x22
---[ end trace 7ce940aff1366d60 ]---

Fix the problem by skipping the encoder get_config() function for
inactive encoders.
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some card's max brightness level is pretty large, e.g. on Acer Aspire
4732Z, the max level is 989910. If user space set a large enough level
then the current scale done in intel_panel_set_backlight will cause an
integer overflow and the scaled level will be mistakenly small, leaving
user with an almost black screen. This patch fixes this problem.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
[danvet: Add a comment to explain what's going on.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The DRM layer keeps track of our vblanks and it assumes our vblank
counters only go back to zero when they overflow. The problem is that
when we disable the power well our counters also go to zero, but it
doesn't mean they did overflow. So on this patch we grab the lock and
update last_vblank so the DRM layer won't think our counters
overflowed.

This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblank

Regression introduced by the following commit:

commit bf51d5e2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Wed Jul 3 17:12:13 2013 -0300
    drm/i915: switch disable_power_well default value to 1

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Added a comment that this might be better done in
drm_vblank_post_modeset in general.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently Bspec is wrong in this case here even for gm45. Note that
Bspec is horribly misguided on i965g/gm, so we don't have any other
data points besides that it seems to make machines work better.

With this changes all the bits in PORT_HOTPLUG_STAT for the digital
ports are ordered the same way. This seems to agree with what register
dumps from the hpd storm handling code shows, where the LIVE bit and
the short/long pulse STATUS bits light up at the same time with this
enumeration (but no with the one from Bspec).

Also tested on my gm45 which has two DP+ ports, and everything seems
to still work as expected.

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html
Cc: Egbert Eich <eich@suse.com>
Cc: Jan Niggemann <jn@hz6.de>
Tested-by: NJan Niggemann <jn@hz6.de>
[danvet: Add a big warning that Bspec seems to be wrong for these
bits, suggested by Jani.]
Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

same fix as cirrus and mgag200.

Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

When a BO gets pinned the placement may get changed. If the memory is
mapped into user space and user space has already accessed the mapped
range the page tables are set up but now point to the wrong memory.
Set bo.mdev->dev_mapping in mgag200_bo_create() to make sure that
ttm_bo_unmap_virtual() called from ttm_bo_handle_move_mem() will take
care of this.

v2: Don't call ttm_bo_unmap_virtual() in mgag200_bo_pin(), fix comment.
Signed-off-by: NEgbert Eich <eich@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a cirrus version of Egbert Eich's patch for mgag200.

Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked
called from ttm_bo_handle_move_mem returns with no effect. If any
application accessed the memory before it was moved, it will
access wrong memory next time. This causes crashes when changing
resolution down.
Signed-off-by: NMichal Srb <msrb@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>