30 May, 2018
6 commits
-
[ Upstream commit e88230a3744a71a0b5ecfb45e08ddfe1c884e50d ]
The plane buffer address/stride/height was incorrectly updated in the
plane_atomic_update operation instead of the vsync irq.
This patch delays this operation in the vsync irq along with the
other plane delayed setup.This issue was masked using legacy framebuffer and X11 modesetting, but
is clearly visible using gbm rendering when buffer is submitted late after
vblank, like using software decoding and OpenGL rendering in Kodi.
With this patch, tearing and other artifacts disappears completely.Cc: Michal Lazo
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Neil Armstrong
Acked-by: Daniel Vetter
Link: https://patchwork.freedesktop.org/patch/msgid/1518689976-23292-1-git-send-email-narmstrong@baylibre.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1293b6191010672c0c9dacae8f71c6f3e4d70cbe ]
Due to a typo, the mask was destroyed by a comparison instead of a bit
shift.Signed-off-by: Wolfram Sang
Signed-off-by: Inki Dae
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a588a8bb7b25a3fb4f7fed00feb7aec541fc2632 ]
The exynos DRM driver uses real-time 'struct timeval' values
for exporting its timestamps to user space. This has multiple
problems:1. signed seconds overflow in y2038
2. the 'struct timeval' definition is deprecated in the kernel
3. time may jump or go backwards after a 'settimeofday()' syscall
4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
can't be compared
5. exporting microseconds requires a division by 1000, which may
be slow on some architectures.The code existed in two places before, but the IPP portion was
removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM
IPP subsystem"), so we no longer need to worry about it.Ideally timestamps should just use 64-bit nanoseconds instead, but
of course we can't change that now. Instead, this tries to address
the first four points above by using monotonic 'timespec' values.According to Tobias Jakobi, user space doesn't care about the
timestamp at the moment, so we can change the format. Even if
there is something looking at them, it will work just fine with
monotonic times as long as the application only looks at the
relative values between two events.Link: https://patchwork.kernel.org/patch/10038593/
Cc: Tobias Jakobi
Signed-off-by: Arnd Bergmann
Reviewed-by: Tobias Jakobi
Signed-off-by: Inki Dae
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 3addaba8141bc6a4f649a48f46e552af32922147 ]
Before returning, call of_node_put() for the device node returned by
of_parse_phandle().Fixes: ea9c260514c1 ("gpu: ipu-v3: add driver for Prefetch Resolve Gasket")
Signed-off-by: Tobias Jordan
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit c795f3052b60b01e80485fad98c53e5e67d093c9 ]
Before returning, call of_node_put() for the device node returned by
of_parse_phandle().Fixes: d2a34232580a ("gpu: ipu-v3: add driver for Prefetch Resolve Engine")
Signed-off-by: Tobias Jordan
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit 938ae7259c908ad031da35d551da297640bb640c upstream.
Depending on whether the kernel is compiled with frame-pointer or not,
the temporary memory location used for the bp parameter in these macros
is referenced relative to the stack pointer or the frame pointer.
Hence we can never reference that parameter when we've modified either
the stack pointer or the frame pointer, because then the compiler would
generate an incorrect stack reference.Fix this by pushing the temporary memory parameter on a known location on
the stack before modifying the stack- and frame pointers.Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
Reviewed-by: Sinclair Yeh
Signed-off-by: Greg Kroah-Hartman
23 May, 2018
2 commits
-
commit b579f924a90f42fa561afd8201514fc216b71949 upstream.
Factor in clear values wherever required while updating destination
min/max.References: HSDES#1604444184
Signed-off-by: Michel Thierry
Cc: mesa-dev@lists.freedesktop.org
Cc: Mika Kuoppala
Cc: Oscar Mateo
Reviewed-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Link: https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thierry@intel.com
Cc: stable@vger.kernel.org
Cc: Joonas Lahtinen
Link: https://patchwork.freedesktop.org/patch/msgid/20180514165445.9198-1-michel.thierry@intel.com
(backported from commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman -
commit 7f6df440b8623c441c42d070bf592e2d2c1fa9bb upstream.
This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_link() fails to remove
sysfs created by create_compat_control_link() in drm_dev_register().Fixes: 6449b088dd51 ("drm: Add fake controlD* symlinks for backwards
compat")
Cc: Dave Airlie
Cc: Alex Deucher
Cc: Emil Velikov
Cc: David Herrmann
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Haneen Mohammed
[seanpaul added Fixes and Cc tags]
Signed-off-by: Sean Paul
Link: https://patchwork.freedesktop.org/patch/msgid/20180511041542.GA4253@haneen-vb
Signed-off-by: Greg Kroah-Hartman
16 May, 2018
5 commits
-
commit b5cb2e5a1f64d882a155add7522247ab0523051e upstream.
Clear the old_state and new_state pointers for private objects
in drm_atomic_state_default_clear(). We don't actually have
functions to get the new/old state for private objects so
getting access to the potentially stale pointers requires a
bit more manual labour than for other object types. But let's
clear the pointers for private objects as well, if only to
avoid future surprises when someone decides to add the functions
to get at them.v2: Split private objs to a separate patch (Daniel)
Cc: # v4.14+
Cc: Maarten Lankhorst
Cc: Laurent Pinchart
Cc: Abhay Kumar
Fixes: a4370c777406 (drm/atomic: Make private objs proper objects)
Signed-off-by: Ville Syrjälä
Link: https://patchwork.freedesktop.org/patch/msgid/20180502183247.5746-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
Signed-off-by: Sean Paul
Signed-off-by: Greg Kroah-Hartman -
commit f0b408eebc993310bea3f2daae286c40bd3f063b upstream.
Clear the old_state and new_state pointers for every object in
drm_atomic_state_default_clear(). Otherwise
drm_atomic_get_{new,old}_*_state() will hand out stale pointers to
anyone who hasn't first confirmed that the object is in fact part of
the current atomic transcation, if they are called after we've done
the ww backoff dance while hanging on to the same drm_atomic_state.For example, handle_conflicting_encoders() looks like it could hit
this since it iterates the full connector list and just calls
drm_atomic_get_new_connector_state() for each.And I believe we have now witnessed this happening at least once in
i915 check_digital_port_conflicts(). Commit 8b69449d2663 ("drm/i915:
Remove last references to drm_atomic_get_existing* macros") changed
the safe drm_atomic_get_existing_connector_state() to the unsafe
drm_atomic_get_new_connector_state(), which opened the doors for
this particular bug there as well.v2: Split private objs out to a separate patch (Daniel)
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Laurent Pinchart
Cc: Abhay Kumar
Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.")
Signed-off-by: Ville Syrjälä
Link: https://patchwork.freedesktop.org/patch/msgid/20180502183247.5746-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
Signed-off-by: Sean Paul
Signed-off-by: Greg Kroah-Hartman -
commit 352672db857290ab5b0e2b6a99c414f92bee024c upstream.
Currently; we're grabbing all of the modesetting locks before adding MST
connectors to fbdev. This isn't actually necessary, and causes a
deadlock as well:======================================================
WARNING: possible circular locking dependency detected
4.17.0-rc3Lyude-Test+ #1 Tainted: G O
------------------------------------------------------
kworker/1:0/18 is trying to acquire lock:
00000000c832f62d (&helper->lock){+.+.}, at: drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]but task is already holding lock:
00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm]which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (crtc_ww_class_mutex){+.+.}:
ww_mutex_lock+0x43/0x80
drm_modeset_lock+0x71/0x130 [drm]
drm_helper_probe_single_connector_modes+0x7d/0x6b0 [drm_kms_helper]
drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper]
__drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
nouveau_fbcon_init+0x138/0x1a0 [nouveau]
nouveau_drm_load+0x173/0x7e0 [nouveau]
drm_dev_register+0x134/0x1c0 [drm]
drm_get_pci_dev+0x8e/0x160 [drm]
nouveau_drm_probe+0x1a9/0x230 [nouveau]
pci_device_probe+0xcd/0x150
driver_probe_device+0x30b/0x480
__driver_attach+0xbc/0xe0
bus_for_each_dev+0x67/0x90
bus_add_driver+0x164/0x260
driver_register+0x57/0xc0
do_one_initcall+0x4d/0x323
do_init_module+0x5b/0x1f8
load_module+0x20e5/0x2ac0
__do_sys_finit_module+0xb7/0xd0
do_syscall_64+0x60/0x1b0
entry_SYSCALL_64_after_hwframe+0x49/0xbe-> #2 (crtc_ww_class_acquire){+.+.}:
drm_helper_probe_single_connector_modes+0x58/0x6b0 [drm_kms_helper]
drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper]
__drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
nouveau_fbcon_init+0x138/0x1a0 [nouveau]
nouveau_drm_load+0x173/0x7e0 [nouveau]
drm_dev_register+0x134/0x1c0 [drm]
drm_get_pci_dev+0x8e/0x160 [drm]
nouveau_drm_probe+0x1a9/0x230 [nouveau]
pci_device_probe+0xcd/0x150
driver_probe_device+0x30b/0x480
__driver_attach+0xbc/0xe0
bus_for_each_dev+0x67/0x90
bus_add_driver+0x164/0x260
driver_register+0x57/0xc0
do_one_initcall+0x4d/0x323
do_init_module+0x5b/0x1f8
load_module+0x20e5/0x2ac0
__do_sys_finit_module+0xb7/0xd0
do_syscall_64+0x60/0x1b0
entry_SYSCALL_64_after_hwframe+0x49/0xbe-> #1 (&dev->mode_config.mutex){+.+.}:
drm_setup_crtcs+0x10c/0xc90 [drm_kms_helper]
__drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper]
nouveau_fbcon_init+0x138/0x1a0 [nouveau]
nouveau_drm_load+0x173/0x7e0 [nouveau]
drm_dev_register+0x134/0x1c0 [drm]
drm_get_pci_dev+0x8e/0x160 [drm]
nouveau_drm_probe+0x1a9/0x230 [nouveau]
pci_device_probe+0xcd/0x150
driver_probe_device+0x30b/0x480
__driver_attach+0xbc/0xe0
bus_for_each_dev+0x67/0x90
bus_add_driver+0x164/0x260
driver_register+0x57/0xc0
do_one_initcall+0x4d/0x323
do_init_module+0x5b/0x1f8
load_module+0x20e5/0x2ac0
__do_sys_finit_module+0xb7/0xd0
do_syscall_64+0x60/0x1b0
entry_SYSCALL_64_after_hwframe+0x49/0xbe-> #0 (&helper->lock){+.+.}:
__mutex_lock+0x70/0x9d0
drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
nv50_mstm_register_connector+0x2c/0x50 [nouveau]
drm_dp_add_port+0x2f5/0x420 [drm_kms_helper]
drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
drm_dp_add_port+0x33f/0x420 [drm_kms_helper]
drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper]
drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper]
process_one_work+0x20d/0x650
worker_thread+0x3a/0x390
kthread+0x11e/0x140
ret_from_fork+0x3a/0x50other info that might help us debug this:
Chain exists of:
&helper->lock --> crtc_ww_class_acquire --> crtc_ww_class_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(crtc_ww_class_mutex);
lock(crtc_ww_class_acquire);
lock(crtc_ww_class_mutex);
lock(&helper->lock);*** DEADLOCK ***
5 locks held by kworker/1:0/18:
#0: 000000004a05cd50 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x187/0x650
#1: 00000000601c11d1 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x187/0x650
#2: 00000000586ca0df (&dev->mode_config.mutex){+.+.}, at: drm_modeset_lock_all+0x3a/0x1b0 [drm]
#3: 00000000d3ca0ffa (crtc_ww_class_acquire){+.+.}, at: drm_modeset_lock_all+0x44/0x1b0 [drm]
#4: 00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm]stack backtrace:
CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G O 4.17.0-rc3Lyude-Test+ #1
Hardware name: Gateway FX6840/FX6840, BIOS P01-A3 05/17/2010
Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
Call Trace:
dump_stack+0x85/0xcb
print_circular_bug.isra.38+0x1ce/0x1db
__lock_acquire+0x128f/0x1350
? lock_acquire+0x9f/0x200
? lock_acquire+0x9f/0x200
? __ww_mutex_lock.constprop.13+0x8f/0x1000
lock_acquire+0x9f/0x200
? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
__mutex_lock+0x70/0x9d0
? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
? ww_mutex_lock+0x43/0x80
? _cond_resched+0x15/0x30
? ww_mutex_lock+0x43/0x80
? drm_modeset_lock+0xb2/0x130 [drm]
? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper]
nv50_mstm_register_connector+0x2c/0x50 [nouveau]
drm_dp_add_port+0x2f5/0x420 [drm_kms_helper]
? mark_held_locks+0x50/0x80
? kfree+0xcf/0x2a0
? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper]
? trace_hardirqs_on_caller+0xed/0x180
? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper]
drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
drm_dp_add_port+0x33f/0x420 [drm_kms_helper]
? nouveau_connector_aux_xfer+0x7c/0xb0 [nouveau]
? find_held_lock+0x2d/0x90
? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper]
? __mutex_unlock_slowpath+0x3b/0x280
? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper]
drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper]
drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper]
process_one_work+0x20d/0x650
worker_thread+0x3a/0x390
? process_one_work+0x650/0x650
kthread+0x11e/0x140
? kthread_create_worker_on_cpu+0x50/0x50
ret_from_fork+0x3a/0x50Taking example from i915, the only time we need to hold any modesetting
locks is when changing the port on the mstc, and in that case we only
need to hold the connection mutex.Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: stable@vger.kernel.org
Signed-off-by: Lyude Paul
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit e8f48f96db7e482995743f461b3e8a5c1a102533 upstream.
Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
power on` in kernel log at boot time.Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
on its screen during Intel i915 DRM initialization. This currently
results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
panel to power on` message appearing in the kernel log during boot
time and when stopping the machine.This change increases the timeout of the `intel_enable_lvds` function
from 1 to 5 seconds, letting enough time for the Satellite 930 LCD
screen to power on, and suppressing the error message from the kernel
log.This patch has been successfully tested on Linux 4.14 running on a
Toshiba Satellite Z930.[vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
code and properly cover the max hw timeout of ~4 seconds, and
drop the comment about the specific machine since this is not
a particulary surprising issue, nor specific to that one machine]Signed-off-by: Florent Flament
Cc: stable@vger.kernel.org
Cc: Pavel Petrovic
Cc: Sérgio M. Basto
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
References: https://bugzilla.kernel.org/show_bug.cgi?id=57591
Signed-off-by: Ville Syrjälä
Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula
(cherry picked from commit 280b54ade5914d3b4abe4f0ebe083ddbd4603246)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman -
commit 9a0e9802217291e54c4dd1fc5462f189a4be14ec upstream.
When using uni-planar formats (like RGB), the scaling parameters are
stored in plane 0, not plane 1.Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Cc: stable@vger.kernel.org
Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
Link: https://patchwork.freedesktop.org/patch/msgid/20180507121303.5610-1-boris.brezillon@bootlin.com
Signed-off-by: Greg Kroah-Hartman
09 May, 2018
2 commits
-
commit 49ceda9de2da4d1827941d06701f3017c27c1855 upstream.
edid should be freed once it's finished being used.
Fixes: 56fe8b6f4991 ("drm/bridge: Add RGB to VGA bridge support")
Cc: Rob Herring
Cc: Sean Paul
Cc: Maxime Ripard
Cc: Archit Taneja
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: # v4.9+
Reviewed-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
Signed-off-by: Sean Paul
Link: https://patchwork.freedesktop.org/patch/msgid/20180420190007.1572-1-seanpaul@chromium.org
Signed-off-by: Greg Kroah-Hartman -
commit 13f149d47392782baafd96d54d4e65f3b5ca342f upstream.
A buffer object leak was introduced when fixing a premature buffer
object release. Fix this.Cc:
Fixes: 73a88250b709 ("Fix a destoy-while-held mutex problem.")
Signed-off-by: Thomas Hellstrom
Reviewed-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
Signed-off-by: Greg Kroah-Hartman
02 May, 2018
3 commits
-
commit ac315c621f01d4b8a53dec317c7ae322fd26ff38 upstream.
The DMC FW specific part of display WA#1183 is supposed to be enabled
whenever enabling DC5 or DC6, so move it to the DC6 enable function
from the DC6 disable function.I noticed this after Daniel's patch to remove the unused
skl_disable_dc6() function.Fixes: 53421c2fe99c ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc:
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
(cherry picked from commit b49be6622f08187129561cff0409f7b06b33de57)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman -
commit 75569c182e4f65cd8826a5853dc9cbca703cbd0e upstream.
Otherwise, the SQ may skip some of the register writes, or shader waves may
be allocated where we don't expect them, so that as a result we don't actually
reset all of the register SRAMs. This can lead to spurious ECC errors later on
if a shader uses an uninitialized register.Signed-off-by: Nicolai Hähnle
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit d02d270014f70dcab0117776b81a37b6fca745ae upstream.
Wait until we have enough space in the virt queue to actually queue up
our request. Avoids the guest spinning in case we have a non-zero
amount of free entries but not enough for the request.Cc: stable@vger.kernel.org
Reported-by: Alain Magloire
Signed-off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
Link: http://patchwork.freedesktop.org/patch/msgid/20180403095904.11152-1-kraxel@redhat.com
Signed-off-by: Sean Paul
Signed-off-by: Greg Kroah-Hartman
29 Apr, 2018
1 commit
-
commit 9c305eb442f3b371fc722ade827bbf673514123e upstream.
The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
identified needing this workaround.
This patch adds the corresponding version to enable a single iteration for
this specific version.Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on device version")
Acked-by: Archit Taneja
[narmstrong: s/identifies/identified and rebased against Jernej's change]
Signed-off-by: Neil Armstrong
Link: https://patchwork.freedesktop.org/patch/msgid/1519386277-25902-1-git-send-email-narmstrong@baylibre.com
[narmstrong: v4.14 to v4.16 backport]
Cc: # 4.14.x
Signed-off-by: Greg Kroah-Hartman
26 Apr, 2018
7 commits
-
[ Upstream commit fe9748b7b41cee11f8db57fb8b20bc540a33102a ]
Fixes failure to compile with recent envyas as a result of the 'movw'
alias being removed for v5.A bit of history:
v3 only has a 16-bit sign-extended immediate mov op. In order to set
the high bits, there's a separate 'sethi' op. envyas validates that
the value passed to mov(imm) is between -0x8000 and 0x7fff. In order
to simplify macros that load both the low and high word, a 'movw'
alias was added which takes an unsigned 16-bit immediate. However the
actual hardware op still sign extends.v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op
is gone (loads 0 into the dst reg). However due to a bug in envyas,
the movw alias still existed, and selected the no-longer-present v3
16-bit immediate mov op. As a result usage of movw on v5 is the same
as mov with a 0x0 argument.The proper fix throughout is to only ever use the 'movw' alias in
combination with 'sethi'. Anything else should get the sign-extended
validation to ensure that the intended value ends up in the
destination register.Changes in fuc3 binaries is the result of a different encoding being
selected for a mov with an 8-bit value.v2: added commit message written by Ilia, thanks for that!
v3: messed up rebasing, now it should applySigned-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit 5e1df40f40ee45a97bb1066c3d71f0ae920a9672 upstream.
Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)This issue is similar to
commit 2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK
change notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.v2:
- s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)Cc: Chris Wilson
Cc: Ville Syrjälä
Cc: # v4.4+
Acked-by: Chris Wilson (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
(cherry picked from commit e76019a81921e87a4d9e7b3d86102bc708a6c227)
Signed-off-by: Rodrigo Vivi
(Rebased for v4.14 stable tree due to upstream cdclk_state and pcu_lock change)
Signed-off-by: Imre Deak
Signed-off-by: Greg Kroah-Hartman -
commit 7eb2c4dd54ff841f2fe509a84973eb25fa20bda2 upstream.
LSPCON adapters in low-power state may ignore the first I2C write during
TMDS output buffer enabling, resulting in a blank screen even with an
otherwise enabled pipe. Fix this by reading back and validating the
written value a few times.The problem was noticed on GLK machines with an onboard LSPCON adapter
after entering/exiting DC5 power state. Doing an I2C read of the adapter
ID as the first transaction - instead of the I2C write to enable the
TMDS buffers - returns the correct value. Based on this we assume that
the transaction itself is sent properly, it's only the adapter that is
not ready for some reason to accept this first write after waking from
low-power state. In my case the second I2C write attempt always
succeeded.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
Cc: Clinton Taylor
Cc: Ville Syrjälä
Cc: stable@vger.kernel.org
Signed-off-by: Imre Deak
Signed-off-by: Jani Nikula
Link: https://patchwork.freedesktop.org/patch/msgid/20180416155309.11100-1-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman -
commit fcf1fadf4c65eea6c519c773d2d9901e8ad94f5f upstream.
Along the eb_lookup_vmas() error path, the return value from
kmem_cache_alloc() was freed using kfree(). Fix it to use the proper
kmem_cache_free() instead.Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: Xidong Wang
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v4.14+
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
Link: https://patchwork.freedesktop.org/patch/msgid/20180404093824.9313-1-chris@chris-wilson.co.uk
(cherry picked from commit 6be1187dbffa0027ea379c53f7ca0c782515c610)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman -
commit b4615730530be85fc45ab4631c2ad6d8e2d0b97d upstream.
On Geminilake, sometimes audio card is not getting
detected after reboot. This is a spurious issue happening on
Geminilake. HW codec and HD audio controller link was going
out of sync for which there was a fix in i915 driver but
was not getting invoked for GLK. Extending this fix to GLK as well.Tested by Du,Wenkai on GLK board.
Bspec: 21829
v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N)
Cc: # b651bd2a3ae3 ("drm/i915/audio: Fix audio enumeration issue on BXT")
Cc:
Signed-off-by: Gaurav K Singh
Reviewed-by: Abhay Kumar
Signed-off-by: Jani Nikula
Link: https://patchwork.freedesktop.org/patch/msgid/1523989338-29677-1-git-send-email-gaurav.k.singh@intel.com
(cherry picked from commit 8221229046e862977ae93ec9d34aa583fbd10397)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman -
commit 9f591ae60e1be026901398ef99eede91237aa3a1 upstream.
On unknown/unhandled ioctls the driver should return an error, so
userspace knows it tried to use something unsupported.Cc: stable@vger.kernel.org
Signed-off-by: Gerd Hoffmann
Reviewed-by: Alex Williamson
Signed-off-by: Zhenyu Wang
Signed-off-by: Greg Kroah-Hartman -
commit c0db1b677e1d584fab5d7ac76a32e1c0157542e0 upstream.
During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being
freed leading to leaking many 128B allocations. Fix the memory leak by
releasing it at teardown time.Cc: stable@vger.kernel.org
Fixes: 6d45c81d229d ("drm/vc4: Add support for branching in shader validation.")
Signed-off-by: Daniel J Blueman
Signed-off-by: Eric Anholt
Reviewed-by: Eric Anholt
Link: https://patchwork.freedesktop.org/patch/msgid/20180402071035.25356-1-daniel@quora.org
Signed-off-by: Greg Kroah-Hartman
24 Apr, 2018
9 commits
-
commit 5deae9191130db6b617c94fb261804597cf9b508 upstream.
Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).On CHV pipe B we were actually doing the right thing already because we
progammed the custom CSC matrix to do expect limited range input. Now
that well pre-expand the data out with the color correction unit, we
need to change the CSC matrix to operate with full range input instead.This should make the sprite output of the other pipes match the sprite
output of pipe B reasonably well. Looking at the resulting pipe CRCs,
there can be a slight difference in the output, but as I don't know
the formula used by the fixed function CSC of the other pipes, I don't
think it's worth the effort to try to match the output exactly. It
might not even be possible due to difference in internal precision etc.One slight caveat here is that the color correction registers are single
bufferred, so we should really be updating them during vblank, but we
still don't have a mechanism for that, so just toss in another FIXME.v2: Rebase
v3: s/bri/brightness/ s/con/contrast/ (Shashank)
v4: Clarify the constants and math (Shashank)Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Stone
Cc: Russell King - ARM Linux
Cc: Ilia Mirkin
Cc: Hans Verkuil
Cc: Shashank Sharma
Cc: Uma Shankar
Cc: Jyri Sarha
Cc: "Tang, Jun"
Reported-by: "Tang, Jun"
Cc: stable@vger.kernel.org
Fixes: 7f1f3851feb0 ("drm/i915: sprite support for ValleyView v4")
Reviewed-by: Shashank Sharma
Signed-off-by: Ville Syrjälä
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-5-ville.syrjala@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 85e290d92b4b794d0c758c53007eb4248d385386 upstream.
Two years ago I tried an AMD Radeon E8860 embedded GPU with the drm driver.
The dmesg output included driver warnings about an invalid PCIe lane width.
Tracking the problem back led to si_set_pcie_lane_width_in_smc().
The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and
ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting
value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere.
Applying the increment silenced the warnings.
The code has not changed since, so either my analysis was incorrect or the
bug has gone unnoticed. Hence submitting this as an RFC.Acked-by: Christian König
Acked-by: Chunming Zhou
Signed-off-by: Paul Parsons
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit b1550359d1eb392ee54f7cf47cffcfe0a602f6a7 upstream.
With this the dGPU turns on correctly.
Signed-off-by: Nico Sneck
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 5f9e93fed4d45e9a8f84728aff1a8f2ab8922902 upstream.
Calling request_irq() followed by disable_irq() is usually a bad idea,
specially if the interrupt can be pending, and you're not yet in a
position to handle it.This is exactly what happens on my kevin system when rebooting in a
second kernel using kexec: Some interrupt is left pending from
the previous kernel, and we take it too early, before disable_irq()
could do anything.Let's clear the pending interrupts as we initialize the HW, and move
the interrupt request after that point. This ensures that we're in
a sane state when the interrupt is requested.Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier
[adapted to recent rockchip-drm changes]
Signed-off-by: Heiko Stuebner
Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-2-marc.zyngier@arm.com
Signed-off-by: Greg Kroah-Hartman -
commit 20ca25e86c56f5490bdc80318f4fc06466e4c21b upstream.
Required for dpm setup on some asics. Fixes a NULL dereference
on asics that require it.Acked-by: Christian König
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102553
Tested-by: Abel Garcia Dorta
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 41212e2fe72b26ded7ed78224d9eab720c2891e2 upstream.
The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and
ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting
value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere.
Port of the radeon fix to amdgpu.Acked-by: Christian König
Acked-by: Chunming Zhou
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102553
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 4a8e06f7aad797e92413a3042d09d3b385fa1fda upstream.
Needs to be a 32 bit mask.
Acked-by: Huang Rui
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit a20ee0b1f8b42e2568f3a4408003d22b2dfcc706 upstream.
If these bos are evicted and are in the validated list
things blow up, so do not put them in there. Notably,
that tries to add the bo to the LRU twice, which results
in a BUG_ON in ttm_bo.c.While for the bo_list an alternative would be to not allow
always valid bos in there, that does not work for the user
fence.v2: Fixed whitespace issue pointed out by checkpatch.pl
Signed-off-by: Bas Nieuwenhuizen
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 13b40935cf64f59b93cf1c716a2033488e5a228c upstream.
_PR3 doesn't seem to work properly, use ATPX instead.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104064
Reviewed-by: Huang Rui
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
19 Apr, 2018
1 commit
-
commit c02216acf4177c4411d33735c81cad687790fa59 upstream.
In randconfig testing, we sometimes get this warning:
drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp]
#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \This is rather annoying since almost all other code produces no build-time
output unless we have found a real bug. We already fixed this in the
amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for
compile testing") by adding a CONFIG_COMPILE_TEST check last year and
agreed to do the same here, but both Michel and I then forgot about it
until I came across the issue again now.For stable kernels, as this is one of very few remaining randconfig
warnings in 4.14.Cc: stable@vger.kernel.org
Link: https://patchwork.kernel.org/patch/9550009/
Signed-off-by: Arnd Bergmann
Signed-off-by: Michel Dänzer
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
12 Apr, 2018
1 commit
-
[ Upstream commit 12a26c298d2a8b1cab498533fa65198e49e3afd3 ]
divider_recalc_rate() is an helper function used by clock divider of
different types, so the structure containing the 'hw' pointer is not
always a 'struct clk_divider'At the following line:
> div = _get_div(table, val, flags, divider->width);in several cases, the value of 'divider->width' is garbage as the actual
structure behind this memory is not a 'struct clk_divider'Fortunately, this width value is used by _get_val() only when
CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
far when the structure is not a 'struct clk_divider'. This is probably
why we did not notice this bug beforeFixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero")
Signed-off-by: Jerome Brunet
Acked-by: Alexandre Belloni
Acked-by: Sylvain Lemieux
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
29 Mar, 2018
3 commits
-
commit e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31 upstream.
The vk cts test:
dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporarytriggers a lot of
VFS: Close: file count is 0Dave pointed out that clearing the syncobj->file from
drm_syncobj_file_release() was sufficient to silence the test, but that
opens a can of worm since we assumed that the syncobj->file was never
unset. Stop trying to reuse the same struct file for every fd pointing
to the drm_syncobj, and allocate one file for each fd instead.v2: Fixup return handling of drm_syncobj_fd_to_handle
v2.1: [airlied: fix possible syncobj ref race]
v2.2: [jekstrand: back-port to 4.14]Reported-by: Dave Airlie
Signed-off-by: Chris Wilson
Tested-by: Dave Airlie
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Jason Ekstrand
Tested-by: Clayton Craft
Signed-off-by: Greg Kroah-Hartman -
commit 3b82a4db8eaccce735dffd50b4d4e1578099b8e8 upstream.
The memmap options sent to the udl framebuffer driver were not being
checked for all sets of possible crazy values. Fix this up by properly
bounding the allowed values.Reported-by: Eyal Itkin
Cc: stable
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Link: https://patchwork.freedesktop.org/patch/msgid/20180321154553.GA18454@kroah.com
Signed-off-by: Greg Kroah-Hartman -
commit b24791fe00f8b089d5b10cb7bcc4e1ae88b4831b upstream.
getfb can only return a single plane, so reject attempts to use it with
multi-plane framebuffers.Signed-off-by: Daniel Stone
Reported-by: Daniel van Vugt
Reviewed-by: Rob Clark
Reviewed-by: Daniel Vetter
Fixes: 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel format v5")
Cc: stable@vger.kernel.org # v3.3+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105518
Link: https://patchwork.freedesktop.org/patch/msgid/20180320225839.30905-1-daniels@collabora.com
Signed-off-by: Greg Kroah-Hartman
