This is a note to let you know that I've just added the patch titled
Revert "drm/radeon: dont switch vt on suspend"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-drm-radeon-dont-switch-vt-on-suspend.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 18c437caa5b18a235dd65cec224eab54bebcee65 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher(a)amd.com>
Date: Tue, 14 Nov 2017 17:19:29 -0500
Subject: Revert "drm/radeon: dont switch vt on suspend"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Alex Deucher <alexander.deucher(a)amd.com>
commit 18c437caa5b18a235dd65cec224eab54bebcee65 upstream.
Fixes distorted colors on some cards on resume from suspend.
This reverts commit b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99163
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=107001
Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_fb.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -252,7 +252,6 @@ static int radeonfb_create(struct drm_fb
}
info->par = rfbdev;
- info->skip_vt_switch = true;
ret = radeon_framebuffer_init(rdev->ddev, &rfbdev->rfb, &mode_cmd, gobj);
if (ret) {
Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are
queue-4.9/drm-amd-pp-fix-typecast-error-in-powerplay.patch
queue-4.9/drm-ttm-once-more-fix-ttm_buffer_object_transfer.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
queue-4.9/drm-radeon-fix-atombios-on-big-endian.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
queue-4.9/revert-drm-radeon-dont-switch-vt-on-suspend.patch
This is a note to let you know that I've just added the patch titled
NFS: revalidate "." etc correctly on "open".
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfs-revalidate-.-etc-correctly-on-open.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b688741cb06695312f18b730653d6611e1bad28d Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Fri, 25 Aug 2017 17:34:41 +1000
Subject: NFS: revalidate "." etc correctly on "open".
From: NeilBrown <neilb(a)suse.com>
commit b688741cb06695312f18b730653d6611e1bad28d upstream.
For correct close-to-open semantics, NFS must validate
the change attribute of a directory (or file) on open.
Since commit ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a
d_weak_revalidate dentry op"), open() of "." or a path ending ".." is
not revalidated reliably (except when that direct is a mount point).
Prior to that commit, "." was revalidated using nfs_lookup_revalidate()
which checks the LOOKUP_OPEN flag and forces revalidation if the flag is
set.
Since that commit, nfs_weak_revalidate() is used for NFSv3 (which
ignores the flags) and nothing is used for NFSv4.
This is fixed by using nfs_lookup_verify_inode() in
nfs_weak_revalidate(). This does the revalidation exactly when needed.
Also, add a definition of .d_weak_revalidate for NFSv4.
The incorrect behavior is easily demonstrated by running "echo *" in
some non-mountpoint NFS directory while watching network traffic.
Without this patch, "echo *" sometimes doesn't produce any traffic.
With the patch it always does.
Fixes: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op")
cc: stable(a)vger.kernel.org (3.9+)
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/dir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1292,7 +1292,7 @@ static int nfs_weak_revalidate(struct de
return 0;
}
- error = nfs_revalidate_inode(NFS_SERVER(inode), inode);
+ error = nfs_lookup_verify_inode(inode, flags);
dfprintk(LOOKUPCACHE, "NFS: %s: inode %lu is %s\n",
__func__, inode->i_ino, error ? "invalid" : "valid");
return !error;
@@ -1443,6 +1443,7 @@ static int nfs4_lookup_revalidate(struct
const struct dentry_operations nfs4_dentry_operations = {
.d_revalidate = nfs4_lookup_revalidate,
+ .d_weak_revalidate = nfs_weak_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
.d_automount = nfs_d_automount,
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.9/nfs-revalidate-.-etc-correctly-on-open.patch
This is a note to let you know that I've just added the patch titled
nvme-pci: add quirk for delay before CHK RDY for WDC SN200
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nvme-pci-add-quirk-for-delay-before-chk-rdy-for-wdc-sn200.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8c97eeccf0ad8783c057830119467b877bdfced7 Mon Sep 17 00:00:00 2001
From: Jeff Lien <jeff.lien(a)wdc.com>
Date: Tue, 21 Nov 2017 10:44:37 -0600
Subject: nvme-pci: add quirk for delay before CHK RDY for WDC SN200
From: Jeff Lien <jeff.lien(a)wdc.com>
commit 8c97eeccf0ad8783c057830119467b877bdfced7 upstream.
And increase the existing delay to cover this device as well.
Signed-off-by: Jeff Lien <jeff.lien(a)wdc.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/host/nvme.h | 2 +-
drivers/nvme/host/pci.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -84,7 +84,7 @@ enum nvme_quirks {
* NVME_QUIRK_DELAY_BEFORE_CHK_RDY quirk enabled. The value (in ms) was
* found empirically.
*/
-#define NVME_QUIRK_DELAY_AMOUNT 2000
+#define NVME_QUIRK_DELAY_AMOUNT 2300
enum nvme_ctrl_state {
NVME_CTRL_NEW,
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2109,6 +2109,8 @@ static const struct pci_device_id nvme_i
.driver_data = NVME_QUIRK_IDENTIFY_CNS, },
{ PCI_DEVICE(0x1c58, 0x0003), /* HGST adapter */
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
+ { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */
+ .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
{ PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xffffff) },
Patches currently in stable-queue which might be from jeff.lien(a)wdc.com are
queue-4.9/nvme-pci-add-quirk-for-delay-before-chk-rdy-for-wdc-sn200.patch
This is a note to let you know that I've just added the patch titled
hwmon: (jc42) optionally try to disable the SMBUS timeout
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hwmon-jc42-optionally-try-to-disable-the-smbus-timeout.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 68615eb01f82256c19e41967bfb3eef902f77033 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda(a)axentia.se>
Date: Mon, 27 Nov 2017 17:31:00 +0100
Subject: hwmon: (jc42) optionally try to disable the SMBUS timeout
From: Peter Rosin <peda(a)axentia.se>
commit 68615eb01f82256c19e41967bfb3eef902f77033 upstream.
With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver
is not always capable of avoiding the 25-35 ms timeout as specified by
the SMBUS protocol. This may cause silent corruption of the last bit of
any transfer, e.g. a one is read instead of a zero if the sensor chip
times out. This also affects the eeprom half of the nxp-se97 chip, where
this silent corruption was originally noticed. Other I2C adapters probably
suffer similar issues, e.g. bit-banging comes to mind as risky...
The SMBUS register in the nxp chip is not a standard Jedec register, but
it is not special to the nxp chips either, at least the atmel chips
have the same mechanism. Therefore, do not special case this on the
manufacturer, it is opt-in via the device property anyway.
Signed-off-by: Peter Rosin <peda(a)axentia.se>
Acked-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/hwmon/jc42.txt | 4 ++++
drivers/hwmon/jc42.c | 21 +++++++++++++++++++++
2 files changed, 25 insertions(+)
--- a/Documentation/devicetree/bindings/hwmon/jc42.txt
+++ b/Documentation/devicetree/bindings/hwmon/jc42.txt
@@ -34,6 +34,10 @@ Required properties:
- reg: I2C address
+Optional properties:
+- smbus-timeout-disable: When set, the smbus timeout function will be disabled.
+ This is not supported on all chips.
+
Example:
temp-sensor@1a {
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -22,6 +22,7 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include <linux/bitops.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
@@ -45,6 +46,7 @@ static const unsigned short normal_i2c[]
#define JC42_REG_TEMP 0x05
#define JC42_REG_MANID 0x06
#define JC42_REG_DEVICEID 0x07
+#define JC42_REG_SMBUS 0x22 /* NXP and Atmel, possibly others? */
/* Status bits in temperature register */
#define JC42_ALARM_CRIT_BIT 15
@@ -73,6 +75,9 @@ static const unsigned short normal_i2c[]
#define ONS_MANID 0x1b09 /* ON Semiconductor */
#define STM_MANID 0x104a /* ST Microelectronics */
+/* SMBUS register */
+#define SMBUS_STMOUT BIT(7) /* SMBus time-out, active low */
+
/* Supported chips */
/* Analog Devices */
@@ -476,6 +481,22 @@ static int jc42_probe(struct i2c_client
data->extended = !!(cap & JC42_CAP_RANGE);
+ if (device_property_read_bool(dev, "smbus-timeout-disable")) {
+ int smbus;
+
+ /*
+ * Not all chips support this register, but from a
+ * quick read of various datasheets no chip appears
+ * incompatible with the below attempt to disable
+ * the timeout. And the whole thing is opt-in...
+ */
+ smbus = i2c_smbus_read_word_swapped(client, JC42_REG_SMBUS);
+ if (smbus < 0)
+ return smbus;
+ i2c_smbus_write_word_swapped(client, JC42_REG_SMBUS,
+ smbus | SMBUS_STMOUT);
+ }
+
config = i2c_smbus_read_word_swapped(client, JC42_REG_CONFIG);
if (config < 0)
return config;
Patches currently in stable-queue which might be from peda(a)axentia.se are
queue-4.9/hwmon-jc42-optionally-try-to-disable-the-smbus-timeout.patch
This is a note to let you know that I've just added the patch titled
drm/ttm: once more fix ttm_buffer_object_transfer
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-ttm-once-more-fix-ttm_buffer_object_transfer.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4d98e5ee6084f6d7bc578c5d5f86de7156aaa4cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Mon, 30 Oct 2017 14:57:43 +0100
Subject: drm/ttm: once more fix ttm_buffer_object_transfer
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Christian König <christian.koenig(a)amd.com>
commit 4d98e5ee6084f6d7bc578c5d5f86de7156aaa4cb upstream.
When the mutex is locked just in the moment we copy it we end up with a
warning that we release a locked mutex.
Fix this by properly reinitializing the mutex.
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -473,6 +473,7 @@ static int ttm_buffer_object_transfer(st
INIT_LIST_HEAD(&fbo->lru);
INIT_LIST_HEAD(&fbo->swap);
INIT_LIST_HEAD(&fbo->io_reserve_lru);
+ mutex_init(&fbo->wu_mutex);
fbo->moving = NULL;
drm_vma_node_reset(&fbo->vma_node);
atomic_set(&fbo->cpu_writers, 0);
Patches currently in stable-queue which might be from christian.koenig(a)amd.com are
queue-4.9/drm-ttm-once-more-fix-ttm_buffer_object_transfer.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
This is a note to let you know that I've just added the patch titled
drm/radeon: fix atombios on big endian
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-radeon-fix-atombios-on-big-endian.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4f626a4ac8f57ddabf06d03870adab91e463217f Mon Sep 17 00:00:00 2001
From: Roman Kapl <rka(a)sysgo.com>
Date: Mon, 30 Oct 2017 11:56:13 +0100
Subject: drm/radeon: fix atombios on big endian
From: Roman Kapl <rka(a)sysgo.com>
commit 4f626a4ac8f57ddabf06d03870adab91e463217f upstream.
The function for byteswapping the data send to/from atombios was buggy for
num_bytes not divisible by four. The function must be aware of the fact
that after byte-swapping the u32 units, valid bytes might end up after the
num_bytes boundary.
This patch was tested on kernel 3.12 and allowed us to sucesfully use
DisplayPort on and Radeon SI card. Namely it fixed the link training and
EDID readout.
The function is patched both in radeon and amd drivers, since the functions
and the fixes are identical.
Signed-off-by: Roman Kapl <rka(a)sysgo.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 38 ++++++++++++---------------
drivers/gpu/drm/radeon/atombios_dp.c | 38 ++++++++++++---------------
2 files changed, 36 insertions(+), 40 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1788,34 +1788,32 @@ void amdgpu_atombios_scratch_regs_restor
WREG32(mmBIOS_SCRATCH_0 + i, adev->bios_scratch[i]);
}
-/* Atom needs data in little endian format
- * so swap as appropriate when copying data to
- * or from atom. Note that atom operates on
- * dw units.
+/* Atom needs data in little endian format so swap as appropriate when copying
+ * data to or from atom. Note that atom operates on dw units.
+ *
+ * Use to_le=true when sending data to atom and provide at least
+ * ALIGN(num_bytes,4) bytes in the dst buffer.
+ *
+ * Use to_le=false when receiving data from atom and provide ALIGN(num_bytes,4)
+ * byes in the src buffer.
*/
void amdgpu_atombios_copy_swap(u8 *dst, u8 *src, u8 num_bytes, bool to_le)
{
#ifdef __BIG_ENDIAN
- u8 src_tmp[20], dst_tmp[20]; /* used for byteswapping */
- u32 *dst32, *src32;
+ u32 src_tmp[5], dst_tmp[5];
int i;
+ u8 align_num_bytes = ALIGN(num_bytes, 4);
- memcpy(src_tmp, src, num_bytes);
- src32 = (u32 *)src_tmp;
- dst32 = (u32 *)dst_tmp;
if (to_le) {
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = cpu_to_le32(src32[i]);
- memcpy(dst, dst_tmp, num_bytes);
+ memcpy(src_tmp, src, num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = cpu_to_le32(src_tmp[i]);
+ memcpy(dst, dst_tmp, align_num_bytes);
} else {
- u8 dws = num_bytes & ~3;
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = le32_to_cpu(src32[i]);
- memcpy(dst, dst_tmp, dws);
- if (num_bytes % 4) {
- for (i = 0; i < (num_bytes % 4); i++)
- dst[dws+i] = dst_tmp[dws+i];
- }
+ memcpy(src_tmp, src, align_num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = le32_to_cpu(src_tmp[i]);
+ memcpy(dst, dst_tmp, num_bytes);
}
#else
memcpy(dst, src, num_bytes);
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -45,34 +45,32 @@ static char *pre_emph_names[] = {
/***** radeon AUX functions *****/
-/* Atom needs data in little endian format
- * so swap as appropriate when copying data to
- * or from atom. Note that atom operates on
- * dw units.
+/* Atom needs data in little endian format so swap as appropriate when copying
+ * data to or from atom. Note that atom operates on dw units.
+ *
+ * Use to_le=true when sending data to atom and provide at least
+ * ALIGN(num_bytes,4) bytes in the dst buffer.
+ *
+ * Use to_le=false when receiving data from atom and provide ALIGN(num_bytes,4)
+ * byes in the src buffer.
*/
void radeon_atom_copy_swap(u8 *dst, u8 *src, u8 num_bytes, bool to_le)
{
#ifdef __BIG_ENDIAN
- u8 src_tmp[20], dst_tmp[20]; /* used for byteswapping */
- u32 *dst32, *src32;
+ u32 src_tmp[5], dst_tmp[5];
int i;
+ u8 align_num_bytes = ALIGN(num_bytes, 4);
- memcpy(src_tmp, src, num_bytes);
- src32 = (u32 *)src_tmp;
- dst32 = (u32 *)dst_tmp;
if (to_le) {
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = cpu_to_le32(src32[i]);
- memcpy(dst, dst_tmp, num_bytes);
+ memcpy(src_tmp, src, num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = cpu_to_le32(src_tmp[i]);
+ memcpy(dst, dst_tmp, align_num_bytes);
} else {
- u8 dws = num_bytes & ~3;
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = le32_to_cpu(src32[i]);
- memcpy(dst, dst_tmp, dws);
- if (num_bytes % 4) {
- for (i = 0; i < (num_bytes % 4); i++)
- dst[dws+i] = dst_tmp[dws+i];
- }
+ memcpy(src_tmp, src, align_num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = le32_to_cpu(src_tmp[i]);
+ memcpy(dst, dst_tmp, num_bytes);
}
#else
memcpy(dst, src, num_bytes);
Patches currently in stable-queue which might be from rka(a)sysgo.com are
queue-4.9/drm-radeon-fix-atombios-on-big-endian.patch
This is a note to let you know that I've just added the patch titled
drm/panel: simple: Add missing panel_simple_unprepare() calls
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-panel-simple-add-missing-panel_simple_unprepare-calls.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f3621a8eb59a913612c8e6e37d81f16b649f8b6c Mon Sep 17 00:00:00 2001
From: Jonathan Liu <net147(a)gmail.com>
Date: Mon, 7 Aug 2017 21:55:45 +1000
Subject: drm/panel: simple: Add missing panel_simple_unprepare() calls
From: Jonathan Liu <net147(a)gmail.com>
commit f3621a8eb59a913612c8e6e37d81f16b649f8b6c upstream.
During panel removal or system shutdown panel_simple_disable() is called
which disables the panel backlight but the panel is still powered due to
missing calls to panel_simple_unprepare().
Fixes: d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown")
Signed-off-by: Jonathan Liu <net147(a)gmail.com>
Signed-off-by: Thierry Reding <treding(a)nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -369,6 +369,7 @@ static int panel_simple_remove(struct de
drm_panel_remove(&panel->base);
panel_simple_disable(&panel->base);
+ panel_simple_unprepare(&panel->base);
if (panel->ddc)
put_device(&panel->ddc->dev);
@@ -384,6 +385,7 @@ static void panel_simple_shutdown(struct
struct panel_simple *panel = dev_get_drvdata(dev);
panel_simple_disable(&panel->base);
+ panel_simple_unprepare(&panel->base);
}
static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
Patches currently in stable-queue which might be from net147(a)gmail.com are
queue-4.9/drm-panel-simple-add-missing-panel_simple_unprepare-calls.patch
This is a note to let you know that I've just added the patch titled
drm/hisilicon: Ensure LDI regs are properly configured.
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-hisilicon-ensure-ldi-regs-are-properly-configured.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a2f042430784d86eb2b7a6d2a869f552da30edba Mon Sep 17 00:00:00 2001
From: Peter Griffin <peter.griffin(a)linaro.org>
Date: Tue, 15 Aug 2017 15:14:25 +0100
Subject: drm/hisilicon: Ensure LDI regs are properly configured.
From: Peter Griffin <peter.griffin(a)linaro.org>
commit a2f042430784d86eb2b7a6d2a869f552da30edba upstream.
This patch fixes the following soft lockup:
BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
On weston idle-timeout the IP is powered down and reset
asserted. On weston resume we get a massive vblank
IRQ storm due to the LDI registers having lost some state.
This state loss is caused by ade_crtc_atomic_begin() not
calling ade_ldi_set_mode(). With this patch applied
resuming from Weston idle-timeout works well.
Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org>
Tested-by: John Stultz <john.stultz(a)linaro.org>
Reviewed-by: Xinliang Liu <xinliang.liu(a)linaro.org>
Signed-off-by: Xinliang Liu <xinliang.liu(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -521,9 +521,12 @@ static void ade_crtc_atomic_begin(struct
{
struct ade_crtc *acrtc = to_ade_crtc(crtc);
struct ade_hw_ctx *ctx = acrtc->ctx;
+ struct drm_display_mode *mode = &crtc->state->mode;
+ struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
if (!ctx->power_on)
(void)ade_power_up(ctx);
+ ade_ldi_set_mode(acrtc, mode, adj_mode);
}
static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
Patches currently in stable-queue which might be from peter.griffin(a)linaro.org are
queue-4.9/drm-hisilicon-ensure-ldi-regs-are-properly-configured.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 78aa02c713fcf19e9bc8511ab61a5fd6c877cc01 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 30 Sep 2017 11:14:13 +0300
Subject: drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 78aa02c713fcf19e9bc8511ab61a5fd6c877cc01 upstream.
After commit ea09729c9302 ("drm/amdgpu: rework page directory filling
v2") then it becomes a lot harder to verify that "r" is initialized. My
static checker complains and so I've reviewed the code. It does look
like it might be buggy... Anyway, it doesn't hurt to set "r" to zero
at the start.
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -744,7 +744,7 @@ error_free:
int amdgpu_vm_update_page_directory(struct amdgpu_device *adev,
struct amdgpu_vm *vm)
{
- int r;
+ int r = 0;
r = amdgpu_vm_update_pd_or_shadow(adev, vm, true);
if (r)
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 40a9960b046290939b56ce8e51f365258f27f264 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 30 Sep 2017 11:13:28 +0300
Subject: drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 40a9960b046290939b56ce8e51f365258f27f264 upstream.
We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
amdgpu_cs_sysvm_access_required into find_mapping") and now my static
checker complains that "r" might not be initialized at the end of the
function. I've reviewed the code, and that seems possible, but it's
also possible I may have missed something.
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -648,7 +648,7 @@ int amdgpu_vce_ring_parse_cs(struct amdg
uint32_t allocated = 0;
uint32_t tmp, handle = 0;
uint32_t *size = &tmp;
- int i, r, idx = 0;
+ int i, r = 0, idx = 0;
r = amdgpu_cs_sysvm_access_required(p);
if (r)
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
queue-4.9/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch