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.14-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.14 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
@@ -534,9 +534,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.14/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/fsl-dcu: Don't set connector DPMS property
to the 4.14-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-fsl-dcu-don-t-set-connector-dpms-property.patch
and it can be found in the queue-4.14 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 daee54263c1202cbdab85c5e15ae30b417602efb Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Date: Fri, 10 Nov 2017 17:38:34 +0100
Subject: drm/fsl-dcu: Don't set connector DPMS property
From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
commit daee54263c1202cbdab85c5e15ae30b417602efb upstream.
Since commit 4a97a3da420b ("drm: Don't update property values for atomic
drivers") atomic drivers must not update property values as properties
are read from the state instead. To catch remaining users, the
drm_object_property_set_value() function now throws a warning when
called by atomic drivers on non-immutable properties, and we hit that
warning when creating connectors.
The easy fix is to just remove the drm_object_property_set_value() as it
is used here to set the initial value of the connector's DPMS property
to OFF. The DPMS property applies on top of the connector's state crtc
pointer (initialized to NULL) that is the main connector on/off control,
and should thus default to ON.
Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -----
1 file changed, 5 deletions(-)
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct f
{
struct drm_encoder *encoder = &fsl_dev->encoder;
struct drm_connector *connector = &fsl_dev->connector.base;
- struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
int ret;
fsl_dev->connector.encoder = encoder;
@@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct f
if (ret < 0)
goto err_sysfs;
- drm_object_property_set_value(&connector->base,
- mode_config->dpms_property,
- DRM_MODE_DPMS_OFF);
-
ret = drm_panel_attach(panel, connector);
if (ret) {
dev_err(fsl_dev->dev, "failed to attach panel\n");
Patches currently in stable-queue which might be from laurent.pinchart+renesas(a)ideasonboard.com are
queue-4.14/drm-fsl-dcu-don-t-set-connector-dpms-property.patch
This is a note to let you know that I've just added the patch titled
drm/fb_helper: Disable all crtc's when initial setup fails.
to the 4.14-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-fb_helper-disable-all-crtc-s-when-initial-setup-fails.patch
and it can be found in the queue-4.14 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 52dd06506e9bbc2a37b352df7dfc5468f8da21fd Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Date: Tue, 28 Nov 2017 12:16:03 +0100
Subject: drm/fb_helper: Disable all crtc's when initial setup fails.
From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
commit 52dd06506e9bbc2a37b352df7dfc5468f8da21fd upstream.
Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.
Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Reported-by: Thomas Voegtle <tv(a)lio96.de>
Tested-by: Thomas Voegtle <tv(a)lio96.de>
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_fb_helper.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,10 @@ static int drm_fb_helper_single_fb_probe
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+
+ /* First time: disable all crtc's.. */
+ if (!fb_helper->deferred_setup && !READ_ONCE(fb_helper->dev->master))
+ restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
Patches currently in stable-queue which might be from maarten.lankhorst(a)linux.intel.com are
queue-4.14/drm-fb_helper-disable-all-crtc-s-when-initial-setup-fails.patch
This is a note to let you know that I've just added the patch titled
drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
to the 4.14-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-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch
and it can be found in the queue-4.14 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 9271c0ca573e02a360b636ecd8cb408852f4e9f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Wed, 8 Nov 2017 17:25:04 +0200
Subject: drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
commit 9271c0ca573e02a360b636ecd8cb408852f4e9f6 upstream.
Apparently some sinks look at the YQ bits even when receiving RGB,
and they get somehow confused when they see a non-zero YQ value.
So we can't just blindly follow CEA-861-F and set YQ to match the
RGB range.
Unfortunately there is no good way to tell whether the sink
designer claims to have read CEA-861-F. The CEA extension block
revision number has generally been stuck at 3 since forever,
and even a very recently manufactured sink might be based on
an old design so the manufacturing date doesn't seem like
something we can use. In lieu of better information let's
follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
The alternative would of course be to always set YQ=0. And if
we ever encounter a HDMI 2.0+ sink with this bug that's what
we'll probably have to do.
Cc: Jani Nikula <jani.nikula(a)intel.com>
Cc: Eric Anholt <eric(a)anholt.net>
Cc: Neil Kownacki <njkkow(a)gmail.com>
Reported-by: Neil Kownacki <njkkow(a)gmail.com>
Tested-by: Neil Kownacki <njkkow(a)gmail.com>
Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.…
Acked-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 12 ++++++++++--
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
include/drm/drm_edid.h | 3 ++-
4 files changed, 16 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4809,7 +4809,8 @@ void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
- bool rgb_quant_range_selectable)
+ bool rgb_quant_range_selectable,
+ bool is_hdmi2_sink)
{
/*
* CEA-861:
@@ -4833,8 +4834,15 @@ drm_hdmi_avi_infoframe_quant_range(struc
* YQ-field to match the RGB Quantization Range being transmitted
* (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
* set YQ=1) and the Sink shall ignore the YQ-field."
+ *
+ * Unfortunate certain sinks (eg. VIZ Model 67/E261VA) get confused
+ * by non-zero YQ when receiving RGB. There doesn't seem to be any
+ * good way to tell which version of CEA-861 the sink supports, so
+ * we limit non-zero YQ to HDMI 2.0 sinks only as HDMI 2.0 is based
+ * on on CEA-861-F.
*/
- if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
+ if (!is_hdmi2_sink ||
+ rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
frame->ycc_quantization_range =
HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
else
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -481,7 +481,8 @@ static void intel_hdmi_set_avi_infoframe
crtc_state->limited_color_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
- intel_hdmi->rgb_quant_range_selectable);
+ intel_hdmi->rgb_quant_range_selectable,
+ is_hdmi2_sink);
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, &frame);
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -433,7 +433,8 @@ static void vc4_hdmi_set_avi_infoframe(s
vc4_encoder->limited_rgb_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL,
- vc4_encoder->rgb_range_selectable);
+ vc4_encoder->rgb_range_selectable,
+ false);
vc4_hdmi_write_infoframe(encoder, &frame);
}
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -360,7 +360,8 @@ void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode,
enum hdmi_quantization_range rgb_quant_range,
- bool rgb_quant_range_selectable);
+ bool rgb_quant_range_selectable,
+ bool is_hdmi2_sink);
/**
* drm_eld_mnl - Get ELD monitor name length in bytes.
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-4.14/drm-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch
queue-4.14/drm-vblank-fix-flip-event-vblank-count.patch
queue-4.14/drm-vblank-tune-drm_crtc_accurate_vblank_count-warn-down-to-a-debug.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Set adev->vcn.irq.num_types for VCN
to the 4.14-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-set-adev-vcn.irq.num_types-for-vcn.patch
and it can be found in the queue-4.14 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 89ce6e0afee8eafa679093207dabd717af9d09c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer(a)amd.com>
Date: Wed, 22 Nov 2017 15:55:21 +0100
Subject: drm/amdgpu: Set adev->vcn.irq.num_types for VCN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Michel Dänzer <michel.daenzer(a)amd.com>
commit 89ce6e0afee8eafa679093207dabd717af9d09c5 upstream.
We were setting adev->uvd.irq.num_types instead.
Fixes: 9b257116e784 ("drm/amdgpu: add vcn enc irq support")
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-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/amd/amdgpu/vcn_v1_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -1175,7 +1175,7 @@ static const struct amdgpu_irq_src_funcs
static void vcn_v1_0_set_irq_funcs(struct amdgpu_device *adev)
{
- adev->uvd.irq.num_types = adev->vcn.num_enc_rings + 1;
+ adev->vcn.irq.num_types = adev->vcn.num_enc_rings + 1;
adev->vcn.irq.funcs = &vcn_v1_0_irq_funcs;
}
Patches currently in stable-queue which might be from michel.daenzer(a)amd.com are
queue-4.14/drm-amdgpu-reserve-root-pd-while-releasing-it.patch
queue-4.14/drm-amdgpu-set-adev-vcn.irq.num_types-for-vcn.patch
queue-4.14/drm-amdgpu-fix-error-handling-in-amdgpu_bo_do_create.patch
queue-4.14/drm-ttm-always-and-only-destroy-bo-ttm_resv-in-ttm_bo_release_list.patch
queue-4.14/revert-drm-radeon-dont-switch-vt-on-suspend.patch
queue-4.14/drm-amdgpu-move-uvd-vce-and-vcn-structure-out-from-union.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: reserve root PD while releasing it
to the 4.14-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-reserve-root-pd-while-releasing-it.patch
and it can be found in the queue-4.14 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 2642cf110d08a403f585a051e4cbf45a90b3adea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Fri, 13 Oct 2017 17:24:31 +0200
Subject: drm/amdgpu: reserve root PD while releasing it
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 2642cf110d08a403f585a051e4cbf45a90b3adea upstream.
Otherwise somebody could try to evict it at the same time and try to use
half torn down structures.
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer(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: Lyude Paul <lyude(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2586,7 +2586,8 @@ void amdgpu_vm_fini(struct amdgpu_device
{
struct amdgpu_bo_va_mapping *mapping, *tmp;
bool prt_fini_needed = !!adev->gart.gart_funcs->set_prt;
- int i;
+ struct amdgpu_bo *root;
+ int i, r;
amd_sched_entity_fini(vm->entity.sched, &vm->entity);
@@ -2609,7 +2610,15 @@ void amdgpu_vm_fini(struct amdgpu_device
amdgpu_vm_free_mapping(adev, vm, mapping, NULL);
}
- amdgpu_vm_free_levels(&vm->root);
+ root = amdgpu_bo_ref(vm->root.bo);
+ r = amdgpu_bo_reserve(root, true);
+ if (r) {
+ dev_err(adev->dev, "Leaking page tables because BO reservation failed\n");
+ } else {
+ amdgpu_vm_free_levels(&vm->root);
+ amdgpu_bo_unreserve(root);
+ }
+ amdgpu_bo_unref(&root);
dma_fence_put(vm->last_dir_update);
for (i = 0; i < AMDGPU_MAX_VMHUBS; i++)
amdgpu_vm_free_reserved_vmid(adev, vm, i);
Patches currently in stable-queue which might be from christian.koenig(a)amd.com are
queue-4.14/drm-ttm-fix-ttm_bo_cleanup_refs_or_queue-once-more.patch
queue-4.14/drm-ttm-once-more-fix-ttm_buffer_object_transfer.patch
queue-4.14/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vce_ring_parse_cs.patch
queue-4.14/drm-amdgpu-reserve-root-pd-while-releasing-it.patch
queue-4.14/drm-amdgpu-properly-allocate-vm-invalidate-eng-v2.patch
queue-4.14/drm-amdgpu-set-adev-vcn.irq.num_types-for-vcn.patch
queue-4.14/drm-amdgpu-potential-uninitialized-variable-in-amdgpu_vm_update_directories.patch
queue-4.14/drm-amdgpu-fix-error-handling-in-amdgpu_bo_do_create.patch
queue-4.14/drm-ttm-always-and-only-destroy-bo-ttm_resv-in-ttm_bo_release_list.patch
queue-4.14/dma-buf-make-reservation_object_copy_fences-rcu-save.patch
queue-4.14/drm-amdgpu-move-uvd-vce-and-vcn-structure-out-from-union.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: move UVD/VCE and VCN structure out from union
to the 4.14-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-move-uvd-vce-and-vcn-structure-out-from-union.patch
and it can be found in the queue-4.14 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 b43aaee69d4327d05e7624d9471c17d015b4d67d Mon Sep 17 00:00:00 2001
From: Leo Liu <leo.liu(a)amd.com>
Date: Tue, 21 Nov 2017 09:08:07 -0500
Subject: drm/amdgpu: move UVD/VCE and VCN structure out from union
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Leo Liu <leo.liu(a)amd.com>
commit b43aaee69d4327d05e7624d9471c17d015b4d67d upstream.
With the enablement of VCN Dec and Enc from user space, User space queries
kernel for the IP information, if HW has UVD/VCE, the info comes from these
IP blocks, but this could end up mis-interpret for VCN when they are in the
union, the other way same when HW with VCN block.
Signed-off-by: Leo Liu <leo.liu(a)amd.com>
Acked-by: Alex Deucher <alexander.deucher(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Fixes: 95d0906f8506 ("drm/amdgpu: add initial vcn support and decode tests")
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer(a)amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1536,18 +1536,14 @@ struct amdgpu_device {
/* sdma */
struct amdgpu_sdma sdma;
- union {
- struct {
- /* uvd */
- struct amdgpu_uvd uvd;
+ /* uvd */
+ struct amdgpu_uvd uvd;
- /* vce */
- struct amdgpu_vce vce;
- };
+ /* vce */
+ struct amdgpu_vce vce;
- /* vcn */
- struct amdgpu_vcn vcn;
- };
+ /* vcn */
+ struct amdgpu_vcn vcn;
/* firmwares */
struct amdgpu_firmware firmware;
Patches currently in stable-queue which might be from leo.liu(a)amd.com are
queue-4.14/drm-amdgpu-move-uvd-vce-and-vcn-structure-out-from-union.patch
This is a note to let you know that I've just added the patch titled
drm/amd/pp: fix typecast error in powerplay.
to the 4.14-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-amd-pp-fix-typecast-error-in-powerplay.patch
and it can be found in the queue-4.14 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 8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca Mon Sep 17 00:00:00 2001
From: Rex Zhu <Rex.Zhu(a)amd.com>
Date: Fri, 17 Nov 2017 16:41:16 +0800
Subject: drm/amd/pp: fix typecast error in powerplay.
From: Rex Zhu <Rex.Zhu(a)amd.com>
commit 8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca upstream.
resulted in unexpected data truncation
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu(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/amd/powerplay/hwmgr/process_pptables_v1_0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
@@ -850,9 +850,9 @@ static int init_over_drive_limits(
const ATOM_Tonga_POWERPLAYTABLE *powerplay_table)
{
hwmgr->platform_descriptor.overdriveLimit.engineClock =
- le16_to_cpu(powerplay_table->ulMaxODEngineClock);
+ le32_to_cpu(powerplay_table->ulMaxODEngineClock);
hwmgr->platform_descriptor.overdriveLimit.memoryClock =
- le16_to_cpu(powerplay_table->ulMaxODMemoryClock);
+ le32_to_cpu(powerplay_table->ulMaxODMemoryClock);
hwmgr->platform_descriptor.minOverdriveVDDC = 0;
hwmgr->platform_descriptor.maxOverdriveVDDC = 0;
Patches currently in stable-queue which might be from Rex.Zhu(a)amd.com are
queue-4.14/drm-amd-pp-fix-typecast-error-in-powerplay.patch
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.4-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.4 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
@@ -226,7 +226,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.4/drm-radeon-fix-atombios-on-big-endian.patch
queue-4.4/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
drm/radeon: fix atombios on big endian
to the 4.4-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.4 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
@@ -1575,34 +1575,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.4/drm-radeon-fix-atombios-on-big-endian.patch