Josh Boyer [Thu, 10 Dec 2015 02:12:52 +0000 (21:12 -0500)]
ideapad-laptop: Add Lenovo ideapad Y700-17ISK to no_hw_rfkill dmi list
commit
edde316acb5f07c04abf09a92f59db5d2efd14e2 upstream.
One of the newest ideapad models also lacks a physical hw rfkill switch,
and trying to read the hw rfkill switch through the ideapad module
causes it to always reported blocking breaking wifi.
Fix it by adding this model to the DMI list.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1286293
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Azael Avalos [Mon, 16 Nov 2015 03:32:47 +0000 (20:32 -0700)]
toshiba_acpi: Fix blank screen at boot if transflective backlight is supported
commit
bae5336f0aaedffa115dab9cb3d8a4e4aed3a26a upstream.
If transflective backlight is supported and the brightness is zero
(lowest brightness level), the set_lcd_brightness function will activate
the transflective backlight, making the LCD appear to be turned off.
This patch fixes the issue by incrementing the brightness level, and
by doing so, avoiding the activation of the tranflective backlight.
Reported-and-tested-by: Fabian Koester <fabian.koester@bringnow.com>
Signed-off-by: Azael Avalos <coproscefalo@gmail.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Fri, 22 Jan 2016 23:08:52 +0000 (18:08 -0500)]
make sure that freeing shmem fast symlinks is RCU-delayed
commit
3ed47db34f480df7caf44436e3e63e555351ae9a upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 19 Feb 2016 23:05:10 +0000 (18:05 -0500)]
drm/radeon/pm: adjust display configuration after powerstate
commit
39d4275058baf53e89203407bf3841ff2c74fa32 upstream.
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Fri, 19 Feb 2016 01:06:38 +0000 (02:06 +0100)]
drm/radeon: Don't hang in radeon_flip_work_func on disabled crtc. (v2)
commit
2b8341b3f917c108b47f6a8a771a40d226c57883 upstream.
This fixes a regression introduced in Linux 4.4.
Limit the amount of time radeon_flip_work_func can
delay programming a page flip, by both limiting the
maximum amount of time per wait cycle and the maximum
number of wait cycles. Continue the flip if the limit
is exceeded, even if that may result in a visual or
timing glitch.
This is to prevent a hang of page flips, as reported
in fdo bug #93746: Disconnecting a DisplayPort display
in parallel to a kms pageflip getting queued can cause
the following hang of page flips and thereby an unusable
desktop:
1. kms pageflip ioctl() queues pageflip -> queues execution
of radeon_flip_work_func.
2. Hotunplug of display causes the driver to DPMS OFF
the unplugged display. Display engine shuts down,
scanout no longer moves, but stays at its resting
position at start line of vblank.
3. radeon_flip_work_func executes while crtc is off, and
due to the non-moving scanout position, the new flip
delay code introduced into Linux 4.4 by
commit
5b5561b3660d ("drm/radeon: Fixup hw vblank counter/ts..")
enters an infinite wait loop.
4. After reconnecting the display, the pageflip continues
to hang in 3. and the display doesn't update its view
of the desktop.
This patch fixes the Linux 4.4 regression from fdo bug #93746
<https://bugs.freedesktop.org/show_bug.cgi?id=93746>
v2: Skip wait immediately if !radeon_crtc->enabled, as
suggested by Michel.
Reported-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Fri, 12 Feb 2016 19:30:30 +0000 (20:30 +0100)]
drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)
commit
bb74fc1bf3072bd3ab4ed5f43afd287a63baf2d7 upstream.
drm_vblank_offdelay can have three different types of values:
< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
that way via dev->vblank_disable_immediate. Otherwise it is
a disable timeout in msecs.
This got broken in Linux 3.18+ for the implementation of
drm_vblank_on. If the user specified a value of zero which should
always reenable vblank irqs in this function, a kms driver could
override the users choice by setting vblank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.
v2: Only reenable vblank if there are clients left or the user
requested to "never disable vblanks" via offdelay 0. Enabling
vblanks even in the "delayed disable" case (offdelay > 0) was
specifically added by Ville in commit
cd19e52aee922
("drm: Kick start vblank interrupts at drm_vblank_on()"),
but after discussion it turns out that this was done by accident.
Citing Ville: "I think it just ended up as a mess due to changing
some of the semantics of offdelay<0 vs. offdelay==0 vs.
disable_immediate during the review of the series. So yeah, given
how drm_vblank_put() works now, I'd just make this check for
offdelay==0."
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Fri, 12 Feb 2016 19:30:29 +0000 (20:30 +0100)]
drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4
commit
c61934ed9a0e3911a9935df26858726a7ec35ec0 upstream.
Changes to drm_update_vblank_count() in Linux 4.4 broke the
behaviour of the pre/post modeset functions as the new update
code doesn't deal with hw vblank counter resets inbetween calls
to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
should.
This causes mistreatment of such hw counter resets as counter
wraparound, and thereby large forward jumps of the software
vblank counter which in turn cause vblank event dispatching
and vblank waits to fail/hang --> userspace clients hang.
This symptom was reported on radeon-kms to cause a infinite
hang of KDE Plasma 5 shell's login procedure, preventing users
from logging in.
Fix this by detecting when drm_update_vblank_count() is called
inside a pre->post modeset interval. If so, clamp valid vblank
increments to the safe values 0 and 1, pretty much restoring
the update behavior of the old update code of Linux 4.3 and
earlier. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Vlastimil Babka <vbabka@suse.cz>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Fri, 12 Feb 2016 19:30:28 +0000 (20:30 +0100)]
drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2)
commit
99b8e71597fadd6b2ac85e6e10f221f79dd9c1c1 upstream.
This fixes a regression introduced by the new drm_update_vblank_count()
implementation in Linux 4.4:
Restrict the bump of the software vblank counter in drm_update_vblank_count()
to a safe maximum value of +1 whenever there is the possibility that
concurrent readers of vblank timestamps could be active at the moment,
as the current implementation of the timestamp caching and updating is
not safe against concurrent readers for calls to store_vblank() with a
bump of anything but +1. A bump != 1 would very likely return corrupted
timestamps to userspace, because the same slot in the cache could
be concurrently written by store_vblank() and read by one of those
readers in a non-atomic fashion and without the read-retry logic
detecting this collision.
Concurrent readers can exist while drm_update_vblank_count() is called
from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank-
irq callers. However, all those calls are happening with the vbl_lock
locked thereby preventing a drm_vblank_get(), so the vblank refcount
can't increase while drm_update_vblank_count() is executing. Therefore
a zero vblank refcount during execution of that function signals that
is safe for arbitrary counter bumps if called from outside vblank irq,
whereas a non-zero count is not safe.
Whenever the function is called from vblank irq, we have to assume concurrent
readers could show up any time during its execution, even if the refcount
is currently zero, as vblank irqs are usually only enabled due to the
presence of readers, and because when it is called from vblank irq it
can't hold the vbl_lock to protect it from sudden bumps in vblank refcount.
Therefore also restrict bumps to +1 when the function is called from vblank
irq.
Such bumps of more than +1 can happen at other times than reenabling
vblank irqs, e.g., when regular vblank interrupts get delayed by more
than 1 frame due to long held locks, long irq off periods, realtime
preemption on RT kernels, or system management interrupts.
A better solution would be to rewrite the timestamp caching to use
full seqlocks to allow concurrent writes and reads for arbitrary
vblank counter increments.
v2: Add code comment that this is essentially a hack and should
be replaced by a full seqlock implementation for caching of
timestamps.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mario Kleiner [Fri, 12 Feb 2016 19:30:27 +0000 (20:30 +0100)]
drm: No-Op redundant calls to drm_vblank_off() (v2)
commit
e8235891b33799d597ff4ab5e45afe173a65da30 upstream.
Otherwise if a kms driver calls into drm_vblank_off() more than once
before calling drm_vblank_on() again, the redundant calls to
vblank_disable_and_save() will call drm_update_vblank_count()
while hw vblank counters and vblank timestamping are in a undefined
state during modesets, dpms off etc.
At least with the legacy drm helpers it is not unusual to
get multiple calls to drm_vblank_off and drm_vblank_on, e.g.,
half a dozen calls to drm_vblank_off and two calls to drm_vblank_on
were observed on radeon-kms during dpms-off -> dpms-on transition.
We don't no-op calls from atomic modesetting drivers, as they
should do a proper job of tracking hw state.
Fixes large jumps of the software maintained vblank counter due to
the hardware vblank counter resetting to zero during dpms off or
modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on
instead of drm_vblank_pre/post_modeset().
This fixes a regression caused by the changes made to
drm_update_vblank_count() in Linux 4.4.
v2: Don't no-op on atomic modesetting drivers, per suggestion
of Daniel Vetter.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rasmus Villemoes [Mon, 15 Feb 2016 18:41:47 +0000 (19:41 +0100)]
drm/radeon: use post-decrement in error handling
commit
bc3f5d8c4ca01555820617eb3b6c0857e4df710d upstream.
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gerd Hoffmann [Tue, 16 Feb 2016 13:25:00 +0000 (14:25 +0100)]
drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command
commit
34855706c30d52b0a744da44348b5d1cc39fbe51 upstream.
This avoids integer overflows on 32bit machines when calculating
reloc_info size, as reported by Alan Cox.
Cc: gnomes@lxorguk.ukuu.org.uk
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rasmus Villemoes [Tue, 9 Feb 2016 20:11:13 +0000 (21:11 +0100)]
drm/i915: fix error path in intel_setup_gmbus()
commit
ed3f9fd1e865975ceefdb2a43b453e090b1fd787 upstream.
This fails to undo the setup for pin==0; moreover, something
interesting happens if the setup failed already at pin==0.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Fixes: f899fc64cda8 ("drm/i915: use GMBUS to manage i2c links")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk
(cherry picked from commit
2417c8c03f508841b85bf61acc91836b7b0e2560)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jani Nikula [Thu, 4 Feb 2016 10:50:50 +0000 (12:50 +0200)]
drm/i915/dsi: don't pass arbitrary data to sideband
commit
26f6f2d301c1fb46acb1138ee155125815239b0d upstream.
Since sequence block v2 the second byte contains flags other than just
pull up/down. Don't pass arbitrary data to the sideband interface.
The rest may or may not work for sequence block v2, but there should be
no harm done.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/ebe3c2eee623afc4b3a134533b01f8d591d13f32.1454582914.git.jani.nikula@intel.com
(cherry picked from commit
4e1c63e3761b84ec7d87c75b58bbc8bcf18e98ee)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jani Nikula [Thu, 4 Feb 2016 10:50:49 +0000 (12:50 +0200)]
drm/i915/dsi: defend gpio table against out of bounds access
commit
4db3a2448ec8902310acb78de39b6227a9a56ac8 upstream.
Do not blindly trust the VBT data used for indexing.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/cc32d40c2b47f2d2151811855ac2c3dabab1d57d.1454582914.git.jani.nikula@intel.com
(cherry picked from commit
5d2d0a12d3d08bf50434f0b5947bb73bac04b941)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lyude [Tue, 2 Feb 2016 15:49:43 +0000 (10:49 -0500)]
drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()
commit
3d849b02336be103d312c1574d6f7314d5c0bc9f upstream.
We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a
result we skip assigning a DPLL to any DP MST ports, which makes link
training fail:
[ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well
[ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well
[ 1442.933957] [drm:intel_mst_pre_enable_dp] 0
[ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels
00000000
[ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0
[ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0
[ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels
05000000
[ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1
[ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1
[ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels
08000000
[ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2
…
[ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
[ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting
After which the pipe state goes completely out of sync:
[ 70.075596] [drm:check_crtc_state] [CRTC:25]
[ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001)
[ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0)
[ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021)
[ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173)
[ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5)
[ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256)
[ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500)
And if you're especially lucky, it keeps going downhill:
[ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
[ 83.309265]
[ 83.309265] =================================
[ 83.309266] [ INFO: inconsistent lock state ]
[ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted
[ 83.309267] ---------------------------------
[ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes:
[ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<
ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915]
[ 83.309293] {IN-HARDIRQ-W} state was registered at:
[ 83.309297] [<
ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00
[ 83.309299] [<
ffffffff810ea1be>] lock_acquire+0xce/0x1c0
[ 83.309302] [<
ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90
[ 83.309321] [<
ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915]
[ 83.309332] [<
ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915]
[ 83.309337] [<
ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300
[ 83.309339] [<
ffffffff810fdeb9>] handle_irq_event+0x39/0x60
[ 83.309341] [<
ffffffff811010b4>] handle_edge_irq+0x74/0x130
[ 83.309344] [<
ffffffff81009073>] handle_irq+0x73/0x120
[ 83.309346] [<
ffffffff817805f1>] do_IRQ+0x61/0x120
[ 83.309348] [<
ffffffff8177e6d6>] ret_from_intr+0x0/0x20
[ 83.309351] [<
ffffffff815f5105>] cpuidle_enter_state+0x105/0x330
[ 83.309353] [<
ffffffff815f5367>] cpuidle_enter+0x17/0x20
[ 83.309356] [<
ffffffff810dbe1a>] call_cpuidle+0x2a/0x50
[ 83.309358] [<
ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0
[ 83.309360] [<
ffffffff817701da>] rest_init+0x13a/0x140
[ 83.309363] [<
ffffffff81f2af8e>] start_kernel+0x475/0x482
[ 83.309365] [<
ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c
[ 83.309367] [<
ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a
Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming")
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com
(cherry picked from commit
78385cb398748debb7ea2e36d6d2001830c172bc)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Fri, 15 Jan 2016 18:46:53 +0000 (20:46 +0200)]
drm/i915: Don't reject primary plane windowing with color keying enabled on SKL+
commit
6f94b6dd006909a5ef6435cc0af557e945240f48 upstream.
On SKL+ plane scaling is mutually exclusive with color keying. The code
check for this, but during some refactoring the code got changed to
also reject primary plane windowing when color keying is used. There is
no such restriction in the hardware, so restore the original logic.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 061e4b8d650a ("drm/i915: clean up atomic plane check functions, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452883613-28549-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit
693bdc28a733dba68b86af295e7509812fec35d9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jani Nikula [Wed, 13 Jan 2016 14:35:20 +0000 (16:35 +0200)]
drm/i915/dp: fall back to 18 bpp when sink capability is unknown
commit
5efd407674068dede403551bea3b0b134c32513a upstream.
Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.
The clamping has been HDMI specific since its introduction in
commit
996a2239f93b03c5972923f04b097f65565c5bed
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 19 11:24:34 2013 +0200
drm/i915: Disable high-bpc on pre-1.4 EDID screens
Reported-and-tested-by: Dihan Wickremasuriya <nayomal@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit
013dd9e038723bbd2aa67be51847384b75be8253)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Francisco Jerez [Thu, 14 Jan 2016 02:59:39 +0000 (18:59 -0800)]
drm/i915: Make sure DC writes are coherent on flush.
commit
935a0ff0e1ea62a116848c0a187b13838f7b9cee upstream.
We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
that writes performed via the HDC are visible in memory. Fixes an
intermittent failure in a Piglit test that writes to a BO from a
shader using GL atomic counters (implemented as HDC untyped atomics)
and then expects the memory to read back the same value after mapping
it on the CPU.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298
Tested-by: Mark Janes <mark.a.janes@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452740379-3194-1-git-send-email-currojerez@riseup.net
(cherry picked from commit
965fd602a6436f689f4f2fe40a6789582778ccd5)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Wed, 13 Jan 2016 10:55:28 +0000 (11:55 +0100)]
drm/i915: Init power domains early in driver load
commit
f5949141a21ee16edf1beaf95cbae7e419171ab5 upstream.
Since
commit
ac9b8236551d1177fd07b56aef9b565d1864420d
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Nov 27 18:55:26 2015 +0200
drm/i915: Introduce a gmbus power domain
gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.
v2: Adjust cleanup paths too (Chris).
v3: Rebase onto -nightly (totally bogus tree I had lying around) and
also move dpio init head (Ville).
v4: Ville instead suggested to move gmbus setup later in the sequence,
since it's only needed by the modeset code.
v5: Move even close to the actual user, right next to the comment that
states where we really need gmbus (and interrupts!).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
References: http://www.spinics.net/lists/intel-gfx/msg83075.html
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452682528-19437-1-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lyude [Thu, 7 Jan 2016 15:43:28 +0000 (10:43 -0500)]
drm/i915: intel_hpd_init(): Fix suspend/resume reprobing
commit
2dc2f761dea65069485110d24eaa5b0d5d808b07 upstream.
This fixes reprobing of display connectors on resume. After some
talking with danvet on IRC, I learned that calling
drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
connector's status. It turns out this is the actual reason reprobing on
resume hasn't been working (this was observed on a T440s):
- We call hpd_init()
- We check each connector for a couple of things before marking
connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
active encoder. Of course, a disconnected port won't have an
active encoder, so we don't add the flag to any of the
connectors.
- We call drm_helper_hpd_irq_event()
- drm_helper_irq_event() checks each connector for the
DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1,
so we skip reprobing each connector except that one.
In addition, we also now avoid setting connector->polled to
DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is
handled by the mst helpers. This is probably what was originally
intended to happen here.
Changes since V1:
* Use the explanation of the issue as the commit message instead
* Change the title of the commit, since this does more then just stop a
check for an encoder now
* Add "Fixes" line for the patch that introduced this regression
* Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors
Changes since V2:
* Put patch changelog above Signed-off-by
* Follow Daniel Vetter's suggestion for making the code here a bit more
legible
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Signed-off-by: Lyude <cpaul@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452181408-14777-1-git-send-email-cpaul@redhat.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit
07c519134417d92c2e1a536e2b66d4ffff4b3be0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Fri, 27 Nov 2015 13:28:55 +0000 (13:28 +0000)]
drm/i915: Restore inhibiting the load of the default context
commit
06ef83a705a98da63797a5a570220b6ca36febd4 upstream.
Following a GPU reset, we may leave the context in a poorly defined
state, and reloading from that context will leave the GPU flummoxed. For
secondary contexts, this will lead to that context being banned - but
currently it is also causing the default context to become banned,
leading to turmoil in the shared state.
This is a regression from
commit
6702cf16e0ba8b0129f5aa1b6609d4e9c70bc13b [v4.1]
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Mon Mar 16 16:00:58 2015 +0000
drm/i915: Initialize all contexts
which quietly introduced the removal of the MI_RESTORE_INHIBIT on the
default context.
v2: Mark the global default context as uninitialized on GPU reset so
that the context-local workarounds are reloaded upon re-enabling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448630935-27377-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: This seems to fix a gpu hand on after the first resume,
resulting in any future suspend operation failing with -EIO because
the gpu seems to be in a funky state. Somehow this patch fixes that.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit
42f1cae8c079bcceb3cff079fddc3ff8852c788f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Insu Yun [Mon, 1 Feb 2016 16:08:29 +0000 (11:08 -0500)]
drm: fix missing reference counting decrease
commit
dabe19540af9e563d526113bb102e1b9b9fa73f9 upstream.
In drm_dp_mst_allocate_vcpi, it returns true in two paths,
but in one path, there is no reference couting decrease.
Signed-off-by: Insu Yun <wuninsu@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolai Hähnle [Fri, 5 Feb 2016 19:35:53 +0000 (14:35 -0500)]
drm/radeon: hold reference to fences in radeon_sa_bo_new
commit
f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.
An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.
Based on the analogous fix for amdgpu.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oded Gabbay [Sat, 30 Jan 2016 05:59:33 +0000 (07:59 +0200)]
drm/radeon: mask out WC from BO on unsupported arches
commit
c5244987394648913ae1a03879c58058a2fc2cee upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Sat, 30 Jan 2016 05:59:32 +0000 (07:59 +0200)]
drm: add helper to check for wc memory support
commit
4b0e4e4af6c6dc8354dcb72182d52c1bc55f12fc upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Slava Grigorev [Tue, 26 Jan 2016 22:35:57 +0000 (17:35 -0500)]
drm/radeon: fix DP audio support for APU with DCE4.1 display engine
commit
fe6fc1f132b4300c1f6defd43a5d673eb60a820d upstream.
Properly setup the DFS divider for DP audio for DCE4.1.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
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>
Slava Grigorev [Tue, 26 Jan 2016 21:56:25 +0000 (16:56 -0500)]
drm/radeon: Add a common function for DFS handling
commit
a64c9dab1c4d05c87ec8a1cb9b48915816462143 upstream.
Move encoding of DFS (digital frequency synthesizer) divider into a
separate function and improve calculation precision.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
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>
Slava Grigorev [Tue, 26 Jan 2016 21:45:10 +0000 (16:45 -0500)]
drm/radeon: cleaned up VCO output settings for DP audio
commit
c9a392eac18409f51a071520cf508c0b4ad990e2 upstream.
This is preparation for the fixes in the following patches.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
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>
Alex Deucher [Fri, 22 Jan 2016 05:13:15 +0000 (00:13 -0500)]
drm/radeon: properly byte swap vce firmware setup
commit
cc78eb22885bba64445cde438ba098de0104920f upstream.
Firmware is LE. Need to properly byteswap some of the fields
so they are interpreted correctly by the driver on BE systems.
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>
Alex Deucher [Thu, 17 Dec 2015 17:52:17 +0000 (12:52 -0500)]
drm/radeon: clean up fujitsu quirks
commit
0eb1c3d4084eeb6fb3a703f88d6ce1521f8fcdd1 upstream.
Combine the two quirks.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=109481
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Slava Grigorev [Thu, 17 Dec 2015 16:09:58 +0000 (11:09 -0500)]
drm/radeon: Fix "slow" audio over DP on DCE8+
commit
ac4a9350abddc51ccb897abf0d9f3fd592b97e0b upstream.
DP audio is derived from the dfs clock.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 24 Nov 2015 19:32:44 +0000 (14:32 -0500)]
drm/radeon: call hpd_irq_event on resume
commit
dbb17a21c131eca94eb31136eee9a7fe5aff00d9 upstream.
Need to call this on resume if displays changes during
suspend in order to properly be notified of changes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Kuehling [Mon, 23 Nov 2015 22:39:11 +0000 (17:39 -0500)]
drm/radeon: Fix off-by-one errors in radeon_vm_bo_set_addr
commit
42ef344c0994cc453477afdc7a8eadc578ed0257 upstream.
eoffset is sometimes treated as the last address inside the address
range, and sometimes as the first address outside the range. This
was resulting in errors when a test filled up the entire address
space. Make it consistent to always be the last address within the
range. Also fixed related errors when checking the VA limit and in
radeon_vm_fence_pts.
Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mykola Lysenko [Wed, 27 Jan 2016 14:39:36 +0000 (09:39 -0500)]
drm/dp/mst: deallocate payload on port destruction
commit
91a25e463130c8e19bdb42f2d827836c7937992e upstream.
This is needed to properly deallocate port payload
after downstream branch get unplugged.
In order to do this unplugged MST topology should
be preserved, to find first alive port on path to
unplugged MST topology, and send payload deallocation
request to branch device of found port.
For this mstb and port kref's are used in reversed
order to track when port and branch memory could be
freed.
Added additional functions to find appropriate mstb
as described above.
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Grodzovsky [Fri, 22 Jan 2016 22:07:29 +0000 (17:07 -0500)]
drm/dp/mst: Reverse order of MST enable and clearing VC payload table.
commit
c175cd16df272119534058f28cbd5eeac6ff2d24 upstream.
On DELL U3014 if you clear the table before enabling MST it sometimes
hangs the receiver.
Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hersen Wu [Fri, 22 Jan 2016 22:07:28 +0000 (17:07 -0500)]
drm/dp/mst: move GUID storage from mgr, port to only mst branch
commit
5e93b8208d3c419b515fb75e2601931c027e12ab upstream.
Previous implementation does not handle case below: boot up one MST branch
to DP connector of ASIC. After boot up, hot plug 2nd MST branch to DP output
of 1st MST, GUID is not created for 2nd MST branch. When downstream port of
2nd MST branch send upstream request, it fails because 2nd MST branch GUID
is not available.
New Implementation: only create GUID for MST branch and save it within Branch.
Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Harry Wentland [Fri, 22 Jan 2016 22:07:26 +0000 (17:07 -0500)]
drm/dp/mst: Calculate MST PBN with 31.32 fixed point
commit
a9ebb3e46c7ef6112c0da466ef0954673ad36832 upstream.
Our PBN value overflows the 20 bits integer part of the 20.12
fixed point. We need to use 31.32 fixed point to avoid this.
This happens with display clocks larger than 293122 (at 24 bpp),
which we see with the Sharp (and similar) 4k tiled displays.
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Harry Wentland [Fri, 22 Jan 2016 22:07:25 +0000 (17:07 -0500)]
drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil
commit
64566b5e767f9bc3161055ca1b443a51afb52aad upstream.
drm_fixp_from_fraction allows us to create a fixed point directly
from a fraction, rather than creating fixed point values and dividing
later. This avoids overflow of our 64 bit value for large numbers.
drm_fixp2int_ceil allows us to return the ceiling of our fixed point
value.
[airlied: squash Jordan's fix]
32-bit-build-fix: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mykola Lysenko [Fri, 25 Dec 2015 08:14:48 +0000 (16:14 +0800)]
drm/dp/mst: fix in RAD element access
commit
7a11a334aa6af4c65c6a0d81b60c97fc18673532 upstream.
This is needed to receive correct port
number from RAD, so MSTB could be found
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mykola Lysenko [Fri, 25 Dec 2015 08:14:47 +0000 (16:14 +0800)]
drm/dp/mst: fix in MSTB RAD initialization
commit
75af4c8c4c0f60d7ad135419805798f144e9baf9 upstream.
This fix is needed to support more then two
branch displays, so RAD address consist at
least of 2 elements
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mykola Lysenko [Fri, 18 Dec 2015 22:14:43 +0000 (17:14 -0500)]
drm/dp/mst: always send reply for UP request
commit
1f16ee7fa13649f4e55aa48ad31c3eb0722a62d3 upstream.
We should always send reply for UP request in order
to make downstream device clean-up resources appropriately.
Issue was that reply for UP request was sent only once.
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mykola Lysenko [Fri, 18 Dec 2015 22:14:42 +0000 (17:14 -0500)]
drm/dp/mst: process broadcast messages correctly
commit
bd9343208704fcc70a5b919f228a7d26ae472727 upstream.
In case broadcast message received in UP request,
RAD cannot be used to identify message originator.
Message should be parsed, originator should be found
by GUID from parsed message.
Also reply with broadcast in case broadcast message
received (for now it is always broadcast)
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thierry Reding [Wed, 24 Feb 2016 17:34:43 +0000 (18:34 +0100)]
drm/nouveau: platform: Fix deferred probe
commit
870571a5698b2e9d0f4d2e5c6245967b582aab45 upstream.
The error cleanup paths aren't quite correct and will crash upon
deferred probe.
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Wed, 17 Feb 2016 22:14:19 +0000 (08:14 +1000)]
drm/nouveau/disp/dp: ensure sink is powered up before attempting link training
commit
95664e66fad964c3dd7945d6edfb1d0931844664 upstream.
This can happen under some annoying circumstances, and is a quick fix
until more substantial changes can be made.
Fixed eDP mode changes on (at least) the Lenovo P50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Fri, 12 Feb 2016 19:30:32 +0000 (20:30 +0100)]
drm/nouveau/display: Enable vblank irqs after display engine is on again.
commit
ff683df7bf34f90766a50c7e7454e219aef2710e upstream.
In the display resume path, move the calls to drm_vblank_on()
after the point when the display engine is running again.
Since changes were made to drm_update_vblank_count() in Linux 4.4+
to emulate hw vblank counters via vblank timestamping, the function
drm_vblank_on() now needs working high precision vblank timestamping
and therefore working scanout position queries at time of call.
These don't work before the display engine gets restarted, causing
miscalculation of vblank counter increments and thereby large forward
jumps in vblank count at display resume. These jumps can cause client
hangs on resume, or desktop hangs in the case of composited desktops.
Fix this Linux 4.4 regression by reordering calls accordingly.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Thu, 7 Jan 2016 22:56:51 +0000 (08:56 +1000)]
drm/nouveau/kms: take mode_config mutex in connector hotplug path
commit
0a882cadbc63fd2da3994af7115b4ada2fcbd638 upstream.
fdo#93634
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 19 Feb 2016 22:55:31 +0000 (17:55 -0500)]
drm/amdgpu/pm: adjust display configuration after powerstate
commit
8e7cedc6f7fe762ffe6e348502be34b11fa79298 upstream.
set_power_state defaults to no displays, so we need to update
the display configuration after setting up the powerstate on the
first call. In most cases this is not an issue since ends up
getting called multiple times at any given modeset and the proper
order is achieved in the display changed handling at the top of
the function.
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jordan Lazare <Jordan.Lazare@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Fri, 19 Feb 2016 01:06:39 +0000 (02:06 +0100)]
drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc.
commit
e1d09dc0ccc6c91e3916476f636edb76da1f65bb upstream.
This fixes a regression introduced in Linux 4.4.
This is a port of the same fix for radeon-kms in the
patch "drm/radeon: Don't hang in radeon_flip_work_func
on disabled crtc. (v2)"
Limit the amount of time amdgpu_flip_work_func can
delay programming a page flip, by both limiting the
maximum amount of time per wait cycle and the maximum
number of wait cycles. Continue the flip if the limit
is exceeded, even if that may result in a visual or
timing glitch.
This is to prevent a hang of page flips, as reported
in fdo bug #93746: Disconnecting a DisplayPort display
in parallel to a kms pageflip getting queued can cause
the following hang of page flips and thereby an unusable
desktop:
1. kms pageflip ioctl() queues pageflip -> queues execution
of amdgpu_flip_work_func.
2. Hotunplug of display causes the driver to DPMS OFF
the unplugged display. Display engine shuts down,
scanout no longer moves, but stays at its resting
position at start line of vblank.
3. amdgpu_flip_work_func executes while crtc is off, and
due to the non-moving scanout position, the new flip
delay code introduced into Linux 4.4 by
commit
8e36f9d33c13 ("drm/amdgpu: Fixup hw vblank counter/ts..")
enters an infinite wait loop.
4. After reconnecting the display, the pageflip continues
to hang in 3. and the display doesn't update its view
of the desktop.
This patch fixes the Linux 4.4 regression from fdo bug #93746
<https://bugs.freedesktop.org/show_bug.cgi?id=93746>
Reported-by: Bernd Steinhauser <linux@bernd-steinhauser.de>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rasmus Villemoes [Mon, 15 Feb 2016 18:41:45 +0000 (19:41 +0100)]
drm/amdgpu: use post-decrement in error handling
commit
09ccbb74b6718ad4d1290de3f5669212c0ac7d4b upstream.
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Mon, 8 Feb 2016 09:57:22 +0000 (10:57 +0100)]
drm/amdgpu: fix issue with overlapping userptrs
commit
cc1de6e800c253172334f8774c419dc64401cd2e upstream.
Otherwise we could try to evict overlapping userptr BOs in get_user_pages(),
leading to a possible circular locking dependency.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolai Hähnle [Fri, 5 Feb 2016 15:59:43 +0000 (10:59 -0500)]
drm/amdgpu: hold reference to fences in amdgpu_sa_bo_new (v2)
commit
a8d81b36267366603771431747438d18f32ae2d5 upstream.
An arbitrary amount of time can pass between spin_unlock and
fence_wait_any_timeout, so we need to ensure that nobody frees the
fences from under us.
A stress test (rapidly starting and killing hundreds of glxgears
instances) ran into a deadlock in fence_wait_any_timeout after
about an hour, and this race condition appears to be a plausible
cause.
v2: agd: rebase on upstream
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolai Hähnle [Fri, 5 Feb 2016 15:49:50 +0000 (10:49 -0500)]
drm/amdgpu: remove unnecessary forward declaration
commit
b19763d0d867eb863953500a5c87f2fd663863b8 upstream.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Flora Cui [Thu, 4 Feb 2016 07:10:08 +0000 (15:10 +0800)]
drm/amdgpu: fix s4 resume
commit
ca19852884c8937eed89560f924f5a34cfcc22af upstream.
No need to re-init asic if it's already been initialized.
Skip IB tests since kernel processes are frozen in thaw.
Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 2 Feb 2016 21:24:20 +0000 (16:24 -0500)]
drm/amdgpu: remove exp hardware support from iceland
commit
dba280b20bfd1c2bed8a07ce3f75a6da8ba7d247 upstream.
It's working now.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=92270
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
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>
Alex Deucher [Tue, 2 Feb 2016 16:15:41 +0000 (11:15 -0500)]
drm/amdgpu: don't load MEC2 on topaz
commit
97dde76a30c2e67fa5fb9cb6a4072c0178c9df26 upstream.
Not validated.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
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>
Alex Deucher [Tue, 2 Feb 2016 15:57:30 +0000 (10:57 -0500)]
drm/amdgpu: drop topaz support from gmc8 module
commit
8878d8548ac7fae43cd6d82579f966eb8825e282 upstream.
topaz is actually gmc7.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
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>
Alex Deucher [Tue, 2 Feb 2016 15:56:15 +0000 (10:56 -0500)]
drm/amdgpu: pull topaz gmc bits into gmc_v7
commit
72b459c8f716ef03a8a0c78078547ce64d8d29a2 upstream.
Add the topaz golden settings into the gmc7 module.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
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>
Ken Wang [Wed, 3 Feb 2016 11:17:53 +0000 (19:17 +0800)]
drm/amdgpu: The VI specific EXE bit should only apply to GMC v8.0 above
commit
8f3c162961fc2d92ec73a66496aab69eb2e19c36 upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ken Wang <Qingqing.Wang@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ken Wang [Wed, 3 Feb 2016 11:16:54 +0000 (19:16 +0800)]
drm/amdgpu: iceland use CI based MC IP
commit
429c45deae6e57f1bb91bfb05b671063fb0cef60 upstream.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ken Wang <Qingqing.Wang@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 2 Feb 2016 15:59:53 +0000 (10:59 -0500)]
drm/amdgpu: move gmc7 support out of CIK dependency
commit
e42d85261680edfc350a6c2a86b7fbb44a85014b upstream.
It's used by iceland which is VI.
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
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>
Alex Deucher [Thu, 28 Jan 2016 21:27:41 +0000 (16:27 -0500)]
drm/amdgpu: no need to load MC firmware on fiji
commit
ad32152eb26043d165eed9406cb9e2f7011f6b10 upstream.
Vbios does this for us on asic_init.
Reviewed-by: Ken Wang >Qingqing.Wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Tue, 19 Jan 2016 11:48:14 +0000 (12:48 +0100)]
drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2
commit
78d0e182b6c1f5336f6e8cbb197f403276dabc7f upstream.
We could pin BOs into invisible VRAM otherwise.
v2: make logic more readable as suggested by Michel
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> (v1)
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 14 Jan 2016 18:48:24 +0000 (13:48 -0500)]
drm/amdgpu: fix tonga smu resume
commit
e160e4db833c7e8587ec3c88efaed0d84f1bcf42 upstream.
Need to make sure smu buffers are pinned on resume. This
matches what Fiji does.
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chunming Zhou [Wed, 13 Jan 2016 04:55:18 +0000 (12:55 +0800)]
drm/amdgpu: fix lost sync_to if scheduler is enabled.
commit
888c9e33e4c5a503285921046c621f7c73199d2f upstream.
when scheduler is enabled, the semaphore isn't used at all.
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 24 Nov 2015 19:30:56 +0000 (14:30 -0500)]
drm/amdgpu: call hpd_irq_event on resume
commit
54fb2a5cd0baf8e97d743de411e2f832d1afa68d upstream.
Need to call this on resume if displays changes during
suspend in order to properly be notified of changes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Kuehling [Mon, 23 Nov 2015 22:43:48 +0000 (17:43 -0500)]
drm/amdgpu: Fix off-by-one errors in amdgpu_vm_bo_map
commit
005ae95e6ec119c64e2d16eb65a94c49e1dcf9f0 upstream.
eaddr is sometimes treated as the last address inside the address
range, and sometimes as the first address outside the range. This
was resulting in errors when a test filled up the entire address
space. Make it consistent to always be the last address within the
range.
Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rob Clark [Wed, 15 Oct 2014 19:00:47 +0000 (15:00 -0400)]
drm/vmwgfx: respect 'nomodeset'
commit
96c5d076f0a5e2023ecdb44d8261f87641ee71e0 upstream.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Fri, 8 Jan 2016 19:29:40 +0000 (20:29 +0100)]
drm/vmwgfx: Fix a width / pitch mismatch on framebuffer updates
commit
a50e2bf5a0f674d62b69f51f6935a30e82bd015c upstream.
When the framebuffer is a vmwgfx dma buffer and a proxy surface is
created, the vmw_kms_update_proxy() function requires that the proxy
surface width and the framebuffer pitch are compatible, otherwise
display corruption occurs as seen in gnome-shell/native with software
3D. Since the framebuffer pitch is determined by user-space, allocate
a proxy surface the width of which is based on the framebuffer pitch
rather than on the framebuffer width.
Reported-by: Raphael Hertzog <buxy@kali.org>
Tested-by: Mati Aharoni <muts@kali.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Fri, 8 Jan 2016 19:29:39 +0000 (20:29 +0100)]
drm/vmwgfx: Fix an incorrect lock check
commit
fb89ac5102ae2875d685c847e6b5dbc141622d43 upstream.
With CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y the vmwgfx kernel module
would unconditionally throw a bug when checking for a held spinlock
in the command buffer code. Fix this by using a lockdep check.
Reported-and-tested-by: Tetsuo Handa <penguin-kernel@i-love-sakura.ne.jp>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael S. Tsirkin [Thu, 14 Jan 2016 14:00:41 +0000 (16:00 +0200)]
virtio_pci: fix use after free on release
commit
2989be09a8a9d62a785137586ad941f916e08f83 upstream.
KASan detected a use-after-free error in virtio-pci remove code. In
virtio_pci_remove(), vp_dev is still used after being freed in
unregister_virtio_device() (in virtio_pci_release_dev() more
precisely).
To fix, keep a reference until cleanup is done.
Fixes: 63bd62a08ca4 ("virtio_pci: defer kfree until release callback")
Reported-by: Jerome Marchand <jmarchan@redhat.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Minchan Kim [Sun, 27 Dec 2015 23:35:13 +0000 (08:35 +0900)]
virtio_balloon: fix race between migration and ballooning
commit
21ea9fb69e7c4b1b1559c3e410943d3ff248ffcb upstream.
In balloon_page_dequeue, pages_lock should cover the loop
(ie, list_for_each_entry_safe). Otherwise, the cursor page could
be isolated by compaction and then list_del by isolation could
poison the page->lru.{prev,next} so the loop finally could
access wrong address like this. This patch fixes the bug.
general protection fault: 0000 [#1] SMP
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 2 PID: 82 Comm: vballoon Not tainted 4.4.0-rc5-mm1-access_bit+ #1906
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task:
ffff8800a7ff0000 ti:
ffff8800a7fec000 task.ti:
ffff8800a7fec000
RIP: 0010:[<
ffffffff8115e754>] [<
ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
RSP: 0018:
ffff8800a7fefdc0 EFLAGS:
00010246
RAX:
ffff88013fff9a70 RBX:
ffffea000056fe00 RCX:
0000000000002b7d
RDX:
ffff88013fff9a70 RSI:
ffffea000056fe00 RDI:
ffff88013fff9a68
RBP:
ffff8800a7fefde8 R08:
ffffea000056fda0 R09:
0000000000000000
R10:
ffff8800a7fefd90 R11:
0000000000000001 R12:
dead0000000000e0
R13:
ffffea000056fe20 R14:
ffff880138809070 R15:
ffff880138809060
FS:
0000000000000000(0000) GS:
ffff88013fc40000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
00007f229c10e000 CR3:
00000000b8b53000 CR4:
00000000000006a0
Stack:
0000000000000100 ffff880138809088 ffff880138809000 ffff880138809060
0000000000000046 ffff8800a7fefe28 ffffffff812c86d3 ffff880138809020
ffff880138809000 fffffffffff91900 0000000000000100 ffff880138809060
Call Trace:
[<
ffffffff812c86d3>] leak_balloon+0x93/0x1a0
[<
ffffffff812c8bc7>] balloon+0x217/0x2a0
[<
ffffffff8143739e>] ? __schedule+0x31e/0x8b0
[<
ffffffff81078160>] ? abort_exclusive_wait+0xb0/0xb0
[<
ffffffff812c89b0>] ? update_balloon_stats+0xf0/0xf0
[<
ffffffff8105b6e9>] kthread+0xc9/0xe0
[<
ffffffff8105b620>] ? kthread_park+0x60/0x60
[<
ffffffff8143b4af>] ret_from_fork+0x3f/0x70
[<
ffffffff8105b620>] ? kthread_park+0x60/0x60
Code: 8d 60 e0 0f 84 af 00 00 00 48 8b 43 20 a8 01 75 3b 48 89 d8 f0 0f ba 28 00 72 10 48 8b 03 f6 c4 08 75 2f 48 89 df e8 8c 83 f9 ff <49> 8b 44 24 20 4d 8d 6c 24 20 48 83 e8 20 4d 39 f5 74 7a 4c 89
RIP [<
ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
RSP <
ffff8800a7fefdc0>
---[ end trace
43cf28060d708d5f ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Rafael Aquini <aquini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Minchan Kim [Sun, 27 Dec 2015 23:35:12 +0000 (08:35 +0900)]
virtio_balloon: fix race by fill and leak
commit
f68b992bbb474641881932c61c92dcfa6f5b3689 upstream.
During my compaction-related stuff, I encountered a bug
with ballooning.
With repeated inflating and deflating cycle, guest memory(
ie, cat /proc/meminfo | grep MemTotal) is decreased and
couldn't be recovered.
The reason is balloon_lock doesn't cover release_pages_balloon
so struct virtio_balloon fields could be overwritten by race
of fill_balloon(e,g, vb->*pfns could be critical).
This patch fixes it in my test.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Henry Chen [Tue, 17 Nov 2015 08:36:49 +0000 (16:36 +0800)]
regulator: mt6311: MT6311_REGULATOR needs to select REGMAP_I2C
commit
aab3c3f34cc2dd8230052770712606d65de6538f upstream.
This patch fix the below build error:
drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c'
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen-Yu Tsai [Tue, 22 Dec 2015 09:08:06 +0000 (17:08 +0800)]
regulator: axp20x: Fix GPIO LDO enable value for AXP22x
commit
3cb99e2ea99a454c8837a55aac88753ef05fc1eb upstream.
The enable/disable values for GPIO LDOs are reversed. It seems no one
noticed as AXP22x support was introduced recently, and no one was using
the GPIO LDOs, either because no designs actually use them or board
support hasn't caught up.
Fixes: 1b82b4e4f954 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Szyprowski [Fri, 11 Dec 2015 14:38:40 +0000 (15:38 +0100)]
clk: exynos: use irqsave version of spin_lock to avoid deadlock with irqs
commit
6b4feaea251a97bf08c7d41eabdec07f63a11073 upstream.
It is allowed to enable/disable clocks from interrupts, so common Exynos
ARM clock management code for CPUfreq should use 'irqsave' version of
spin_lock calls to avoid potential deadlock caused by spin_lock recursion.
The same spin_lock is used by gate/mux clocks during enable/disable calls.
This deadlock, can be reproduced by enabling CPUfreq (ondemand or
userspace) and decoding video with s5p-mfc driver.
Relevant stack trace:
[ 5928.061534] BUG: spinlock recursion on CPU#0, bash/1252
[ 5928.061609] lock: 0xee80454c, .magic:
dead4ead, .owner: bash/1252, .owner_cpu: 0
[ 5928.068586] CPU: 0 PID: 1252 Comm: bash Tainted: G W
4.4.0-rc4-00001-g447a7fd #678
[ 5928.077260] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 5928.083359] [<
c00153dc>] (unwind_backtrace) from [<
c00121b4>] (show_stack+0x10/0x14)
[ 5928.091072] [<
c00121b4>] (show_stack) from [<
c0213e28>] (dump_stack+0x68/0xb8)
[ 5928.098275] [<
c0213e28>] (dump_stack) from [<
c005c1ec>] (do_raw_spin_lock+0x184/0x1ac)
[ 5928.106177] [<
c005c1ec>] (do_raw_spin_lock) from [<
c05cfa98>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 5928.114943] [<
c05cfa98>] (_raw_spin_lock_irqsave) from [<
c0468698>] (clk_gate_endisable+0x24/0x98)
[ 5928.123882] [<
c0468698>] (clk_gate_endisable) from [<
c0464d40>] (clk_core_disable+0x60/0x84)
[ 5928.132299] [<
c0464d40>] (clk_core_disable) from [<
c0465e00>] (clk_disable+0x24/0x30)
[ 5928.140117] [<
c0465e00>] (clk_disable) from [<
c03f3b80>] (s5p_mfc_handle_frame+0x254/0x860)
[ 5928.148445] [<
c03f3b80>] (s5p_mfc_handle_frame) from [<
c03f4b34>] (s5p_mfc_irq+0x890/0xa24)
[ 5928.156778] [<
c03f4b34>] (s5p_mfc_irq) from [<
c00627bc>] (handle_irq_event_percpu+0x50/0x14c)
[ 5928.165283] [<
c00627bc>] (handle_irq_event_percpu) from [<
c00628f0>] (handle_irq_event+0x38/0x5c)
[ 5928.174143] [<
c00628f0>] (handle_irq_event) from [<
c0065864>] (handle_fasteoi_irq+0xdc/0x1a4)
[ 5928.182645] [<
c0065864>] (handle_fasteoi_irq) from [<
c0062090>] (generic_handle_irq+0x18/0x28)
[ 5928.191236] [<
c0062090>] (generic_handle_irq) from [<
c00621a4>] (__handle_domain_irq+0x6c/0xdc)
[ 5928.199917] [<
c00621a4>] (__handle_domain_irq) from [<
c0009470>] (gic_handle_irq+0x4c/0x98)
[ 5928.208249] [<
c0009470>] (gic_handle_irq) from [<
c0012c54>] (__irq_svc+0x54/0x90)
[ 5928.215709] Exception stack(0xeddb5cb8 to 0xeddb5d00)
[ 5928.220745] 5ca0:
ee80454c faddfadc
[ 5928.228906] 5cc0:
00000000 01000001 ee831ce0 f8114200 ee807c00 01130520 00000403 eddb5d84
[ 5928.237063] 5ce0:
ee807c48 2faf0800 ee807c0c eddb5d08 c046b618 c046b634 20000053 ffffffff
[ 5928.245225] [<
c0012c54>] (__irq_svc) from [<
c046b634>] (exynos_cpuclk_notifier_cb+0x170/0x270)
[ 5928.253823] [<
c046b634>] (exynos_cpuclk_notifier_cb) from [<
c003cb58>] (notifier_call_chain+0x44/0x84)
[ 5928.263106] [<
c003cb58>] (notifier_call_chain) from [<
c003ccd4>] (__srcu_notifier_call_chain+0x6c/0x9c)
[ 5928.272480] [<
c003ccd4>] (__srcu_notifier_call_chain) from [<
c003cd1c>] (srcu_notifier_call_chain+0x18/0x20)
[ 5928.282288] [<
c003cd1c>] (srcu_notifier_call_chain) from [<
c0464ed0>] (__clk_notify+0x6c/0x74)
[ 5928.290881] [<
c0464ed0>] (__clk_notify) from [<
c0465388>] (clk_propagate_rate_change+0xa0/0xac)
[ 5928.299561] [<
c0465388>] (clk_propagate_rate_change) from [<
c0465378>] (clk_propagate_rate_change+0x90/0xac)
[ 5928.309370] [<
c0465378>] (clk_propagate_rate_change) from [<
c04666fc>] (clk_core_set_rate_nolock+0x64/0xa8)
[ 5928.319091] [<
c04666fc>] (clk_core_set_rate_nolock) from [<
c0466760>] (clk_set_rate+0x20/0x30)
[ 5928.327686] [<
c0466760>] (clk_set_rate) from [<
c0428c70>] (set_target+0xe8/0x23c)
[ 5928.335152] [<
c0428c70>] (set_target) from [<
c04244d0>] (__cpufreq_driver_target+0x184/0x29c)
[ 5928.343655] [<
c04244d0>] (__cpufreq_driver_target) from [<
c0427128>] (cpufreq_set+0x44/0x64)
[ 5928.352074] [<
c0427128>] (cpufreq_set) from [<
c0423948>] (store_scaling_setspeed+0x5c/0x74)
[ 5928.360407] [<
c0423948>] (store_scaling_setspeed) from [<
c04238d0>] (store+0x7c/0x98)
[ 5928.368221] [<
c04238d0>] (store) from [<
c0132540>] (sysfs_kf_write+0x44/0x48)
[ 5928.375338] [<
c0132540>] (sysfs_kf_write) from [<
c0131b9c>] (kernfs_fop_write+0xb8/0x1bc)
[ 5928.383496] [<
c0131b9c>] (kernfs_fop_write) from [<
c00d71f8>] (__vfs_write+0x2c/0xd4)
[ 5928.391308] [<
c00d71f8>] (__vfs_write) from [<
c00d7de8>] (vfs_write+0xa0/0x144)
[ 5928.398598] [<
c00d7de8>] (vfs_write) from [<
c00d8048>] (SyS_write+0x44/0x84)
[ 5928.405631] [<
c00d8048>] (SyS_write) from [<
c000f540>] (ret_fast_syscall+0x0/0x3c)
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Donnellan [Wed, 4 Nov 2015 02:24:09 +0000 (13:24 +1100)]
cxl: use correct operator when writing pcie config space values
commit
48f0f6b717e314a30be121b67e1d044f6d311d66 upstream.
When writing a value to config space, cxl_pcie_write_config() calls
cxl_pcie_config_info() to obtain a mask and shift value, shifts the new
value accordingly, then uses the mask to combine the shifted value with the
existing value at the address as part of a read-modify-write pattern.
Currently, we use a logical OR operator rather than a bitwise OR operator,
which means any use of this function results in an incorrect value being
written. Replace the logical OR operator with a bitwise OR operator so the
value is written correctly.
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Fixes: 6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API")
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry V. Levin [Sat, 26 Dec 2015 23:13:27 +0000 (02:13 +0300)]
sparc64: fix incorrect sign extension in sys_sparc64_personality
commit
525fd5a94e1be0776fa652df5c687697db508c91 upstream.
The value returned by sys_personality has type "long int".
It is saved to a variable of type "int", which is not a problem
yet because the type of task_struct->pesonality is "unsigned int".
The problem is the sign extension from "int" to "long int"
that happens on return from sys_sparc64_personality.
For example, a userspace call personality((unsigned) -EINVAL) will
result to any subsequent personality call, including absolutely
harmless read-only personality(0xffffffff) call, failing with
errno set to EINVAL.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Tue, 1 Dec 2015 14:52:36 +0000 (15:52 +0100)]
EDAC, mc_sysfs: Fix freeing bus' name
commit
12e26969b32c79018165d52caff3762135614aa1 upstream.
I get the splat below when modprobing/rmmoding EDAC drivers. It happens
because bus->name is invalid after bus_unregister() has run. The Code: section
below corresponds to:
.loc 1 1108 0
movq 672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
.loc 1 1109 0
popq %rbx #
.loc 1 1108 0
movq (%rax), %rdi # _7->name,
jmp kfree #
and %rax has some funky stuff
2030203020312030 which looks a lot like
something walked over it.
Fix that by saving the name ptr before doing stuff to string it points to.
general protection fault: 0000 [#1] SMP
Modules linked in: ...
CPU: 4 PID: 10318 Comm: modprobe Tainted: G I EN 3.12.51-11-default+ #48
Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
task:
ffff880311320280 ti:
ffff88030da3e000 task.ti:
ffff88030da3e000
RIP: 0010:[<
ffffffffa019da92>] [<
ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
RSP: 0018:
ffff88030da3fe28 EFLAGS:
00010292
RAX:
2030203020312030 RBX:
ffff880311b4e000 RCX:
000000000000095c
RDX:
0000000000000001 RSI:
ffff880327bb9600 RDI:
0000000000000286
RBP:
ffff880311b4e750 R08:
0000000000000000 R09:
ffffffff81296110
R10:
0000000000000400 R11:
0000000000000000 R12:
ffff88030ba1ac68
R13:
0000000000000001 R14:
00000000011b02f0 R15:
0000000000000000
FS:
00007fc9bf8f5700(0000) GS:
ffff8801a7c40000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000000000403c90 CR3:
000000019ebdf000 CR4:
00000000000007e0
Stack:
Call Trace:
i7core_unregister_mci.isra.9
i7core_remove
pci_device_remove
__device_release_driver
driver_detach
bus_remove_driver
pci_unregister_driver
i7core_exit
SyS_delete_module
system_call_fastpath
0x7fc9bf426536
Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
RIP [<
ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
RSP <
ffff88030da3fe28>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Fri, 27 Nov 2015 09:38:38 +0000 (10:38 +0100)]
EDAC: Robustify workqueues destruction
commit
fcd5c4dd8201595d4c598c9cca5e54760277d687 upstream.
EDAC workqueue destruction is really fragile. We cancel delayed work
but if it is still running and requeues itself, we still go ahead and
destroy the workqueue and the queued work explodes when workqueue core
attempts to run it.
Make the destruction more robust by switching op_state to offline so
that requeuing stops. Cancel any pending work *synchronously* too.
EDAC i7core: Driver loaded.
general protection fault: 0000 [#1] SMP
CPU 12
Modules linked in:
Supported: Yes
Pid: 0, comm: kworker/0:1 Tainted: G IE 3.0.101-0-default #1 HP ProLiant DL380 G7
RIP: 0010:[<
ffffffff8107dcd7>] [<
ffffffff8107dcd7>] __queue_work+0x17/0x3f0
< ... regs ...>
Process kworker/0:1 (pid: 0, threadinfo
ffff88019def6000, task
ffff88019def4600)
Stack:
...
Call Trace:
call_timer_fn
run_timer_softirq
__do_softirq
call_softirq
do_softirq
irq_exit
smp_apic_timer_interrupt
apic_timer_interrupt
intel_idle
cpuidle_idle_call
cpu_idle
Code: ...
RIP __queue_work
RSP <...>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Mon, 25 Jan 2016 20:32:03 +0000 (20:32 +0000)]
MIPS: Fix buffer overflow in syscall_get_arguments()
commit
f4dce1ffd2e30fa31756876ef502ce6d2324be35 upstream.
Since commit
4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls
(o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall
arguments by incrementing both the start argument number and the number
of arguments to fetch. However only the start argument number needs to
be incremented. The number of arguments does not change, they're just
shifted up by one, and in fact the output array is provided by the
caller and is likely only n entries long, so reading more arguments
overflows the output buffer.
In the case of seccomp, this results in it fetching 7 arguments starting
at the 2nd one, which overflows the unsigned long args[6] in
populate_seccomp_data(). This clobbers the $s0 register from
syscall_trace_enter() which __seccomp_phase1_filter() saved onto the
stack, into which syscall_trace_enter() had placed its syscall number
argument. This caused Chromium to crash.
Credit goes to Milko for tracking it down as far as $s0 being clobbered.
Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
Reported-by: Milko Leporis <milko.leporis@imgtec.com>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12213/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huacai Chen [Thu, 21 Jan 2016 13:09:52 +0000 (21:09 +0800)]
MIPS: Fix some missing CONFIG_CPU_MIPSR6 #ifdefs
commit
4f33f6c522948fffc345261896042b58dea23754 upstream.
Commit
be0c37c985eddc4 (MIPS: Rearrange PTE bits into fixed positions.)
defines fixed PTE bits for MIPS R2. Then, commit
d7b631419b3d230a4d383
(MIPS: pgtable-bits: Fix XPA damage to R6 definitions.) adds the MIPS
R6 definitions in the same way as MIPS R2. But some R6 #ifdefs in the
later commit are missing, so in this patch I fix that.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12164/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huacai Chen [Thu, 21 Jan 2016 13:09:50 +0000 (21:09 +0800)]
MIPS: hpet: Choose a safe value for the ETIME check
commit
5610b1254e3689b6ef8ebe2db260709a74da06c8 upstream.
This patch is borrowed from x86 hpet driver and explaind below:
Due to the overly intelligent design of HPETs, we need to workaround
the problem that the compare value which we write is already behind
the actual counter value at the point where the value hits the real
compare register. This happens for two reasons:
1) We read out the counter, add the delta and write the result to the
compare register. When a NMI hits between the read out and the write
then the counter can be ahead of the event already.
2) The write to the compare register is delayed by up to two HPET
cycles in AMD chipsets.
We can work around this by reading back the compare register to make
sure that the written value has hit the hardware. But that is bad
performance wise for the normal case where the event is far enough in
the future.
As we already know that the write can be delayed by up to two cycles
we can avoid the read back of the compare register completely if we
make the decision whether the delta has elapsed already or not based
on the following calculation:
cmp = event - actual_count;
If cmp is less than 64 HPET clock cycles, then we decide that the event
has happened already and return -ETIME. That covers the above #1 and #2
problems which would cause a wait for HPET wraparound (~306 seconds).
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12162/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huacai Chen [Thu, 21 Jan 2016 13:09:49 +0000 (21:09 +0800)]
MIPS: Loongson-3: Fix SMP_ASK_C0COUNT IPI handler
commit
5754843225f78ac7cbe142a6899890a9733a5a5d upstream.
When Core-0 handle SMP_ASK_C0COUNT IPI, we should make other cores to
see the result as soon as possible (especially when Store-Fill-Buffer
is enabled). Otherwise, C0_Count syncronization makes no sense.
BTW, array is more suitable than per-cpu variable for syncronization,
and there is a corner case should be avoid: C0_Count of Core-0 can be
really 0.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12160/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Fri, 22 Jan 2016 17:20:37 +0000 (09:20 -0800)]
Revert "MIPS: Fix PAGE_MASK definition"
commit
800dc4f49cc002879e1e5e6b79926f86b60528e6 upstream.
This reverts commit
22b14523994588279ae9c5ccfe64073c1e5b3c00.
It was originally sent in an earlier revision of the pfn_t patchset.
Besides being broken, the warning is also fixed by PFN_FLAGS_MASK
casting the PAGE_MASK to an unsigned long.
Reported-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/12182/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zengtao [Tue, 2 Feb 2016 03:38:34 +0000 (11:38 +0800)]
cputime: Prevent 32bit overflow in time[val|spec]_to_cputime()
commit
0f26922fe5dc5724b1adbbd54b21bad03590b4f3 upstream.
The datatype __kernel_time_t is u32 on 32bit platform, so its subject to
overflows in the timeval/timespec to cputime conversion.
Currently the following functions are affected:
1. setitimer()
2. timer_create/timer_settime()
3. sys_clock_nanosleep
This can happen on MIPS32 and ARM32 with "Full dynticks CPU time accounting"
enabled, which is required for CONFIG_NO_HZ_FULL.
Enforce u64 conversion to prevent the overflow.
Fixes: 31c1fc818715 ("ARM: Kconfig: allow full nohz CPU accounting")
Signed-off-by: zengtao <prime.zeng@huawei.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/1454384314-154784-1-git-send-email-prime.zeng@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Gibson [Mon, 30 Nov 2015 01:30:30 +0000 (12:30 +1100)]
time: Avoid signed overflow in timekeeping_get_ns()
commit
35a4933a895927990772ae96fdcfd2f806929ee2 upstream.
1e75fa8 "time: Condense timekeeper.xtime into xtime_sec" replaced a call to
clocksource_cyc2ns() from timekeeping_get_ns() with an open-coded version
of the same logic to avoid keeping a semi-redundant struct timespec
in struct timekeeper.
However, the commit also introduced a subtle semantic change - where
clocksource_cyc2ns() uses purely unsigned math, the new version introduces
a signed temporary, meaning that if (delta * tk->mult) has a 63-bit
overflow the following shift will still give a negative result. The
choice of 'maxsec' in __clocksource_updatefreq_scale() means this will
generally happen if there's a ~10 minute pause in examining the
clocksource.
This can be triggered on a powerpc KVM guest by stopping it from qemu for
a bit over 10 minutes. After resuming time has jumped backwards several
minutes causing numerous problems (jiffies does not advance, msleep()s can
be extended by minutes..). It doesn't happen on x86 KVM guests, because
the guest TSC is effectively frozen while the guest is stopped, which is
not the case for the powerpc timebase.
Obviously an unsigned (64 bit) overflow will only take twice as long as a
signed, 63-bit overflow. I don't know the time code well enough to know
if that will still cause incorrect calculations, or if a 64-bit overflow
is avoided elsewhere.
Still, an incorrect forwards clock adjustment will cause less trouble than
time going backwards. So, this patch removes the potential for
intermediate signed overflow.
Suggested-by: Laurent Vivier <lvivier@redhat.com>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukasz Duda [Wed, 13 Jan 2016 15:57:48 +0000 (16:57 +0100)]
Bluetooth: 6lowpan: Fix handling of uncompressed IPv6 packets
commit
87f5fedb3bebbbb566f847dd0c567fcea49a36a6 upstream.
This patch fixes incorrect handling of the 6lowpan packets that contain
uncompressed IPv6 header.
RFC4944 specifies a special dispatch for 6lowpan to carry uncompressed
IPv6 header. This dispatch (1 byte long) has to be removed during
reception and skb data pointer has to be moved. To correctly point in
the beginning of the IPv6 header the dispatch byte has to be pulled off
before packet can be processed by netif_rx_in().
Test scenario: IPv6 packets are not correctly interpreted by the network
layer when IPv6 header is not compressed (e.g. ICMPv6 Echo Reply is not
propagated correctly to the ICMPv6 layer because the extra byte will make
the header look corrupted).
Similar approach is done for IEEE 802.15.4.
Signed-off-by: Lukasz Duda <lukasz.duda@nordicsemi.no>
Signed-off-by: Glenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Glenn Ruben Bakke [Wed, 13 Jan 2016 15:41:42 +0000 (16:41 +0100)]
Bluetooth: 6lowpan: Fix kernel NULL pointer dereferences
commit
4c58f3282e3de43d34f8955f8eca676294380bf9 upstream.
The fixes provided in this patch assigns a valid net_device structure to
skb before dispatching it for further processing.
Scenario #1:
============
Bluetooth 6lowpan receives an uncompressed IPv6 header, and dispatches it
to netif. The following error occurs:
Null pointer dereference error #1 crash log:
[ 845.854013] BUG: unable to handle kernel NULL pointer dereference at
0000000000000048
[ 845.855785] IP: [<
ffffffff816e3d36>] enqueue_to_backlog+0x56/0x240
...
[ 845.909459] Call Trace:
[ 845.911678] [<
ffffffff816e3f64>] netif_rx_internal+0x44/0xf0
The first modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in order to set a valid net_device before
processing the skb by netif_rx_ni().
Scenario #2:
============
Bluetooth 6lowpan receives an UDP compressed message which needs further
decompression by nhc_udp. The following error occurs:
Null pointer dereference error #2 crash log:
[ 63.295149] BUG: unable to handle kernel NULL pointer dereference at
0000000000000840
[ 63.295931] IP: [<
ffffffffc0559540>] udp_uncompress+0x320/0x626
[nhc_udp]
The second modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in the case of a udp compressed packet.
The 6lowpan udp_uncompress function expects that the net_device is set in
the skb when checking lltype.
Signed-off-by: Glenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
Signed-off-by: Lukasz Duda <lukasz.duda@nordicsemi.no>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hedberg [Tue, 26 Jan 2016 19:31:31 +0000 (14:31 -0500)]
Bluetooth: Fix incorrect removing of IRKs
commit
cff10ce7b4f02718ffd25e3914e60559f5ef6ca0 upstream.
The commit
cad20c278085d893ebd616cd20c0747a8e9d53c7 was supposed to
fix handling of devices first using public addresses and then
switching to RPAs after pairing. Unfortunately it missed a couple of
key places in the code.
1. When evaluating which devices should be removed from the existing
white list we also need to consider whether we have an IRK for them or
not, i.e. a call to hci_find_irk_by_addr() is needed.
2. In smp_notify_keys() we should not be requiring the knowledge of
the RPA, but should simply keep the IRK around if the other conditions
require it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Tunin [Sat, 5 Dec 2015 11:09:36 +0000 (14:09 +0300)]
Bluetooth: Add support of Toshiba Broadcom based devices
commit
1623d0bf847d3b38d8cf24367b3689ba0e3fe2aa upstream.
BugLink: https://bugs.launchpad.net/bugs/1522949
T: Bus=03 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0930 ProdID=0225 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM43142A0
S: SerialNumber=
4CBB58034671
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hedberg [Thu, 3 Dec 2015 10:45:19 +0000 (12:45 +0200)]
Bluetooth: Use continuous scanning when creating LE connections
commit
2f99536a5b34d5b0f54723067d68f6cef3f0fdc6 upstream.
All LE connections are now triggered through a preceding passive scan
and waiting for a connectable advertising report. This means we've got
the best possible guarantee that the device is within range and should
be able to request the controller to perform continuous scanning. This
way we minimize the risk that we miss out on any advertising packets.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
K. Y. Srinivasan [Tue, 15 Dec 2015 00:01:54 +0000 (16:01 -0800)]
Drivers: hv: vmbus: Fix a Host signaling bug
commit
8599846d73997cdbccf63f23394d871cfad1e5e6 upstream.
Currently we have two policies for deciding when to signal the host:
One based on the ring buffer state and the other based on what the
VMBUS client driver wants to do. Consider the case when the client
wants to explicitly control when to signal the host. In this case,
if the client were to defer signaling, we will not be able to signal
the host subsequently when the client does want to signal since the
ring buffer state will prevent the signaling. Implement logic to
have only one signaling policy in force for a given channel.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Tested-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dexuan Cui [Tue, 15 Dec 2015 00:01:58 +0000 (16:01 -0800)]
tools: hv: vss: fix the write()'s argument: error -> vss_msg
commit
a689d2510f188e75391dbebacbddfd74d42f2a7e upstream.
Fix the write()'s argument in the daemon code.
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Tue, 9 Feb 2016 14:12:36 +0000 (16:12 +0200)]
mmc: sdhci: Allow override of get_cd() called from sdhci_request()
commit
8d28b7a72fe18bcdcdb047243ba8fec36b149955 upstream.
Drivers may need to provide their own get_cd() mmc host op, but
currently the internals of the current op (sdhci_get_cd()) are
provided by sdhci_do_get_cd() which is also called from
sdhci_request().
To allow override of the get_cd functionality, change sdhci_request()
to call ->get_cd() instead of sdhci_do_get_cd().
Note, in the future the call to ->get_cd() will likely be removed
from sdhci_request() since most drivers don't need actually it.
However this change is being done now to facilitate a subsequent
bug fix.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Tue, 9 Feb 2016 14:12:35 +0000 (16:12 +0200)]
mmc: sdhci: Allow override of mmc host operations
commit
bf60e592a1af4d6f65dd54593250183f14360eed upstream.
In the past, fixes for specific hardware devices were implemented
in sdhci using quirks. That approach is no longer accepted because
the growing number of quirks was starting to make the code difficult
to understand and maintain.
One alternative to quirks, is to allow drivers to override the default
mmc host operations. This patch makes it easy to do that, and it is
needed for a subsequent bug fix, for which separate patches are
provided.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Tue, 9 Feb 2016 14:12:37 +0000 (16:12 +0200)]
mmc: sdhci-pci: Fix card detect race for Intel BXT/APL
commit
163cbe31e5163459908a41a2b4e0d33a28fd557a upstream.
Intel BXT/APL use a card detect GPIO however the host controller
will not enable bus power unless it's card detect also reflects
the presence of a card. Unfortunately those 2 things race which
can result in commands not starting, after which the controller
does nothing and there is a 10 second wait for the driver's
10-second timer to timeout.
That is fixed by having the driver look also at the present state
register to determine if the card is present. Consequently, provide
a 'get_cd' mmc host operation for BXT/APL that does that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robert Jarzmik [Thu, 28 Jan 2016 23:21:26 +0000 (00:21 +0100)]
mmc: pxamci: fix again read-only gpio detection polarity
commit
41c89159a6ae5472d39ed8bded5b3b4e07a37944 upstream.
The commit fixing the conversion of pxamci to slot-gpio API fixed the
inverted the logic of the read-only gpio. Unfortunately, the commit was
tested on a non-inverted gpio, and not on the inverted one. And the fix
did work partially, by luck.
This is the remaining missing part of the fix, trivial but still necessary.
Fixes: Fixes: 26d49fe71953 ("mmc: pxamci: fix read-only gpio detection polarity")
Reported-by: Andrea Adami <andrea.adami@gmail.com>
Tested-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adrian Hunter [Tue, 9 Feb 2016 14:12:38 +0000 (16:12 +0200)]
mmc: sdhci-acpi: Fix card detect race for Intel BXT/APL
commit
6a645dd87a5a506779810d7d9935c25fc2ef4687 upstream.
Intel BXT/APL use a card detect GPIO however the host controller
will not enable bus power unless it's card detect also reflects
the presence of a card. Unfortunately those 2 things race which
can result in commands not starting, after which the controller
does nothing and there is a 10 second wait for the driver's
10-second timer to timeout.
That is fixed by having the driver look also at the present state
register to determine if the card is present. Consequently, provide
a 'get_cd' mmc host operation for BXT/APL that does that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Mon, 4 Jan 2016 01:21:55 +0000 (02:21 +0100)]
mmc: mmci: fix an ages old detection error
commit
0bcb7efdff63564e80fe84dd36a9fbdfbf6697a4 upstream.
commit
4956e10903fd ("ARM: 6244/1: mmci: add variant data and default
MCICLOCK support") added variant data for ARM, U300 and Ux500 variants.
The Nomadik NHK8815/8820 variant was erroneously labeled as a U300
variant, and when the proper Nomadik variant was later introduced in
commit
34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik MMCI
variant") this was not fixes. Let's say this fixes the latter commit as
there was no proper Nomadik support until then.
Fixes: 34fd421349ff ("ARM: 7378/1: mmci: add support for the Nomadik...")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carlo Caione [Wed, 13 Jan 2016 08:36:55 +0000 (09:36 +0100)]
mmc: core: Enable tuning according to the actual timing
commit
e10c321977091f163eceedec0650e0ef4b3cf4bb upstream.
While in sdhci_execute_tuning() the choice whether or not to enable the
tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
check is done on the capability of the card.
This difference is causing some issues with some SDIO cards in DDR50
mode where the CDM19 is wrongly issued.
With this patch we modify the check in both
mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
only according to the actual timing specification.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / firefly-linux-kernel-4.4.55.git / log