[Bug 101377] Gigabyte R9 380 card fails to load, kernel reports bug
https://bugs.freedesktop.org/show_bug.cgi?id=101377 --- Comment #6 from j...@dev1ce.com --- the problem with this regression to older firmware is that while the kernel boots, none of the 3D functionality inherent in the new drivers is functional. I can regress to an older kernel with the newer firmware 20170622 https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git and the system boots, however with zero 3d support. confirming this bug still exists in 4.12.0 through 4.12.14 as of today. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=101672 --- Comment #19 from MirceaKitsune --- The freeze still happens with the Performance Enhance BIOS setting turned off, the crash is not caused by my overclocking settings. It took 2 hours of playing Minecraft in a row for it to occur again. I noticed an important clue: In the case of Minecraft, the system only seems to crash after mobs have loaded into view. If I only explore a world where no entities spawn (be it full of voxel geometry), the freeze has never happened thus far. This made me realize that all engines I noticed the freeze with have one thing in common: A skeletal mesh is loaded into view. Could this be an issue related to animated models by chance? Note that I don't suspect Vertex Buffer Objects to be a cause: I once turned off VBO in Minecraft, restarted the game, and still got a system freeze. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101631] [amd-staging] RX480 system hang; spamming errors (dc_surface)
https://bugs.freedesktop.org/show_bug.cgi?id=101631 Denys changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101881] [regression] 32bit steam games segfault when launched with DRI_PRIME=1
https://bugs.freedesktop.org/show_bug.cgi?id=101881 --- Comment #6 from Rafael Ristovski --- Also, the llvm issue indeed goes away when adding debug support. I think this might be related to a race condition caused by recent versions of gcc. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt
On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote: > On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > > initialise without an interrupt present. > > > > > > Signed-off-by: Russell King > > > > Hi Russell, > > Sorry for my silence, I was on holiday this week and just came back > today. > > > This isn't fully functional on ARM MPS platforms yet, but at least > > gets us further. Without any display connected: > > > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > > [ 14.557038] tda998x 2-0070: found TDA19988 > > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [ 14.639335] [drm] No driver support for vblank timestamp query. > > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on > > minor 0 > > > > With a TV connected, the driver doesn't initialise: > > > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > > [ 14.657227] tda998x 2-0070: found TDA19988 > > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [ 14.739538] [drm] No driver support for vblank timestamp query. > > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw configuration. > > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > > > I don't think this is correct behaviour - if we fail to set an initial > > configuration (which will be based on the resolution of the connected > > display) why should the driver fail to probe - it's not that there is > > no device, it's (in this case) that there aren't the resources for the > > chosen mode. Userspace could always try setting a different mode. > > > > I suspect the above failure is down to either (a) not having enough > > memory available to allocate a 1920x1080 frame buffer, or (b) not > > (yet) being able to program the hdlcd pixel clock for this platform, > > which is currently hard-coded in DT at 23.75MHz. > > I don't think it is the clock, if that fails then you would not see the > r0p0 version number being printed. Due to the fact that until now HDLCD > has run mostly on platforms that have SCP, which takes care of actual > setup of the clocks, it is pretty lax on errors on pixel clock setup. Note, however, that in this case, the clock is a fixed frequency clock. I wasn't meaning a failure to obtain the clock, I was meaning a failure to set the appropriate rate. > Also, may I ask what MPS platform you are trying to use? I might be able > to source one internally and try to reproduce your problems. I'll point you in the direction of Ian Rickards in ARM for that information. (I'm not sure if I can mention the board publically yet as its early days...) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers
On Thu, Jul 27, 2017 at 6:43 PM, Alex Deucher wrote:
> On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote:
>> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use
>> designated initializers") mark other tableFunction entries with designated
>> initializers. The randstruct plugin requires designated initializers for
>> structures that are entirely function pointers.
>>
>> Cc: Rex Zhu
>> Cc: Hawking Zhang
>> Cc: Alex Deucher
>> Signed-off-by: Kees Cook
>> ---
>> If I can get an Ack for this, I'll carry it in the gcc-plugins tree, unless
>> you think this is worth landing for v4.13, in which case, please take it
>> now. :)
>>
>
> Acked-by: Alex Deucher
>
> I'm happy to take this through my tree if that is ok with you.
Since the randstruct patch depends on this fix, it's likely best to go
through my tree unless you can get this into v4.13. (Since then when
the randstruct patch lands in v4.14, it'll already be there.) I'm fine
either way.
Thanks!
-Kees
--
Kees Cook
Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] drm: rcar-du: Repair vblank for DRM page flips using the VSP
From: Kieran Bingham
The driver recently switched from handling page flip completion in the
DU vertical blanking handler to the VSP frame end handler to fix a race
condition. This unfortunately resulted in incorrect timestamps in the
vertical blanking events sent to userspace as vertical blanking is now
handled after sending the event.
To fix this we must reverse the order of the two operations. The easiest
way is to handle vertical blanking in the VSP frame end handler before
sending the event. The VSP frame end interrupt occurs approximately 50µs
earlier than the DU frame end interrupt, but this should not cause any
undue harm.
As we need to handle vertical blanking even when page flip completion is
delayed, the VSP driver now needs to call the frame end completion
callback unconditionally, with a new argument to report whether page
flip has completed.
With this new scheme the DU vertical blanking interrupt isn't needed
anymore, so we can stop enabling it.
Fixes: d503a43ac06a ("drm: rcar-du: Register a completion callback with VSP1")
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Acked-by: Mauro Carvalho Chehab
---
Changes compared to v2:
- Enable the VBK interrupt when using the VSP as patch 3/4 now needs it
Changes compared to v1:
- Don't enable the VBK interrupt when using the VSP
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 8 +---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 8 ++--
drivers/media/platform/vsp1/vsp1_drm.c | 5 +++--
drivers/media/platform/vsp1/vsp1_drm.h | 2 +-
drivers/media/platform/vsp1/vsp1_pipe.c | 20 ++--
drivers/media/platform/vsp1/vsp1_pipe.h | 2 +-
drivers/media/platform/vsp1/vsp1_video.c | 6 +-
include/media/vsp1.h | 2 +-
9 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 6e5bd0b92dfa..301ea1a8018e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -690,6 +690,7 @@ static int rcar_du_crtc_enable_vblank(struct drm_crtc *crtc)
rcar_du_crtc_write(rcrtc, DSRCR, DSRCR_VBCL);
rcar_du_crtc_set(rcrtc, DIER, DIER_VBE);
+ rcrtc->vblank_enable = true;
return 0;
}
@@ -699,6 +700,7 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc
*crtc)
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
rcar_du_crtc_clr(rcrtc, DIER, DIER_VBE);
+ rcrtc->vblank_enable = false;
}
static const struct drm_crtc_funcs crtc_funcs = {
@@ -743,10 +745,10 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
spin_unlock(&rcrtc->vblank_lock);
if (status & DSSR_VBK) {
- drm_crtc_handle_vblank(&rcrtc->crtc);
-
- if (rcdu->info->gen < 3)
+ if (rcdu->info->gen < 3) {
+ drm_crtc_handle_vblank(&rcrtc->crtc);
rcar_du_crtc_finish_page_flip(rcrtc);
+ }
ret = IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 065b91f5b1d9..fdc2bf99bda1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -32,6 +32,7 @@ struct rcar_du_vsp;
* @mmio_offset: offset of the CRTC registers in the DU MMIO block
* @index: CRTC software and hardware index
* @initialized: whether the CRTC has been initialized and clocks enabled
+ * @vblank_enable: whether vblank events are enabled on this CRTC
* @event: event to post when the pending page flip completes
* @flip_wait: wait queue used to signal page flip completion
* @vblank_lock: protects vblank_wait and vblank_count
@@ -51,6 +52,7 @@ struct rcar_du_crtc {
unsigned int index;
bool initialized;
+ bool vblank_enable;
struct drm_pending_vblank_event *event;
wait_queue_head_t flip_wait;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index e43b065e141a..6de6be3d9090 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -31,11 +31,15 @@
#include "rcar_du_kms.h"
#include "rcar_du_vsp.h"
-static void rcar_du_vsp_complete(void *private)
+static void rcar_du_vsp_complete(void *private, bool completed)
{
struct rcar_du_crtc *crtc = private;
- rcar_du_crtc_finish_page_flip(crtc);
+ if (crtc->vblank_enable)
+ drm_crtc_handle_vblank(&crtc->crtc);
+
+ if (completed)
+ rcar_du_crtc_finish_page_flip(crtc);
}
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 7791d7b5a743..4dfbeac8f42c 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -32,12 +32,13 @@
*
[Bug 94410] [radeonsi] Unreal engine 4 Segmentation fault
https://bugs.freedesktop.org/show_bug.cgi?id=94410 --- Comment #5 from Thomas Kowaliczek --- Screenshost are from version 4.17 after the editor startup freezed my desktop. Only mouse worked. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #18 from Robin --- Created attachment 133127 --> https://bugs.freedesktop.org/attachment.cgi?id=133127&action=edit Logging shutdown function I've modified the patch to include info messages. The code path is never executed in my tests. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101731] System freeze with AMDGPU when playing The Witcher 3
https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #19 from lef...@gmail.com --- I can confirm this happens with radeonsi too -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101731] System freeze with AMDGPU when playing The Witcher 3
https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #20 from Shmerl --- (In reply to Lennard from comment #19) > I can confirm this happens with radeonsi too Well, most previous reports were about radeonsi. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dma-buf/sw_sync: clean up list before signaling the fence
From: Gustavo Padovan
If userspace already dropped its own reference by closing the sw_sync
fence fd we might end up in a deadlock where
dma_fence_is_signaled_locked() will trigger the release of the fence and
thus try to hold the lock to remove the fence from the list.
dma_fence_is_signaled_locked() tries to release/free the fence and hold
the lock in the process.
We fix that by changing the order operation and clean up the list and
rb-tree first.
v2: Drop the fence get/put dance and manipulate the list first (Chris Wilson)
Cc: Chris Wilson
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index ef0cc08..38cc738 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -213,11 +213,21 @@ static void sync_timeline_signal(struct sync_timeline
*obj, unsigned int inc)
obj->value += inc;
list_for_each_entry_safe(pt, next, &obj->pt_list, link) {
- if (!dma_fence_is_signaled_locked(&pt->base))
+ if (!timeline_fence_signaled(&pt->base))
break;
list_del_init(&pt->link);
rb_erase(&pt->node, &obj->pt_tree);
+
+ /*
+* A signal callback may release the last reference to this
+* fence, causing it to be freed. That operation has to be
+* last to avoid a use after free inside this loop, and must
+* be after we remove the fence from the timeline in order to
+* prevent deadlocking on timeline->lock inside
+* timeline_fence_release().
+*/
+ dma_fence_signal_locked(&pt->base);
}
spin_unlock_irq(&obj->lock);
--
2.9.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/i915: Add support for CCS modifiers
Hi Ben,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> + } else if (INTEL_GEN(dev_priv) >= 9) {
> intel_primary_formats = skl_primary_formats;
> num_formats = ARRAY_SIZE(skl_primary_formats);
> - modifiers = skl_format_modifiers;
> + if (pipe >= PIPE_C)
> + modifiers = skl_format_modifiers_ccs;
> + else
> + modifiers = skl_format_modifiers_noccs;
Shouldn't that be (pipe < PIPE_C)?
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence
Hi Chris,
2017-07-28 Chris Wilson :
> Up until recently sync_file were create to export a single dma-fence to
> userspace, and so we could canabalise a bit insie dma-fence to mark
> whether or not we had enable polling for the sync_file itself. However,
> with the advent of syncobj, we do allow userspace to create multiple
> sync_files for a single dma-fence. (Similarly, that the sw-sync
> validation framework also started returning multiple sync-files wrapping
> a single dma-fence for a syncpt also triggering the problem.)
>
> This patch reverts my suggestion in commit e24165537312
> ("dma-buf/sync_file: only enable fence signalling on poll()") to use a
> single bit in the shared dma-fence and restores the sync_file->flags for
> tracking the bits individually.
>
> Reported-by: Gustavo Padovan
> Fixes: f1e8c67123cf ("dma-buf/sw-sync: Use an rbtree to sort fences in the
> timeline")
> Fixes: e9083420bbac ("drm: introduce sync objects (v4)")
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
> Cc: Gustavo Padovan
> Cc: dri-devel@lists.freedesktop.org
> Cc: # v4.13-rc1+
> ---
> drivers/dma-buf/sync_file.c | 5 +++--
> include/linux/sync_file.h | 3 ++-
> 2 files changed, 5 insertions(+), 3 deletions(-)
I confirm the patch fixes the sync kselftests for me. Pushed to
drm-misc-next.
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/i915: Add support for CCS modifiers
Hi,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> +static const uint64_t skl_plane_format_modifiers_noccs[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static const uint64_t skl_plane_format_modifiers[] = {
> + I915_FORMAT_MOD_Yf_TILED_CCS,
> + I915_FORMAT_MOD_Y_TILED_CCS,
> I915_FORMAT_MOD_Yf_TILED,
> I915_FORMAT_MOD_Y_TILED,
> I915_FORMAT_MOD_X_TILED,
This is also missing the relevant hunk in format_mod_supported.
> @@ -1234,6 +1244,19 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> plane_formats = skl_plane_formats;
> num_plane_formats = ARRAY_SIZE(skl_plane_formats);
> modifiers = skl_plane_format_modifiers;
> + } else if (INTEL_GEN(dev_priv) >= 9) {
> + intel_plane->can_scale = true;
> + state->scaler_id = -1;
> +
> + intel_plane->update_plane = skl_update_plane;
> + intel_plane->disable_plane = skl_disable_plane;
> +
> + plane_formats = skl_plane_formats;
> + num_plane_formats = ARRAY_SIZE(skl_plane_formats);
> + if (pipe >= PIPE_C)
> + modifiers = skl_plane_format_modifiers_noccs;
> + else
> + modifiers = skl_plane_format_modifiers;
This explains the inconsistency.
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101969] Massive graphics corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=101969 Bug ID: 101969 Summary: Massive graphics corruption with World of Warcraft Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: ranki...@googlemail.com QA Contact: dri-devel@lists.freedesktop.org World of Warcraft's login screen has become jumbled garbage with the latest Mesa from git. I don't recognise anything as being rendered by WoW, although there are elements from other applications and windows dancing all over the place. I have performed a git bisect, and have identified this commit as the cause: commit 064550238ef0b44e341b2a50c3147f83c2a6d5b0 Author: Marek Olšák Date: Thu Jul 27 02:40:34 2017 +0200 radeonsi: use CLEAR_STATE to initialize some registers Reviewed-by: Nicolai Hähnle :04 04 621668e602ccd2f36299e329b096586baa920ba0 68d43945fde8fbbfad6ae444546a981af2507b03 M src Mesa describes my setup as: Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD BONAIRE (DRM 2.50.0 / 4.12.4, LLVM 5.0.0) (0x665f) Version: 17.3.0 Accelerated: yes Video memory: 2048MB Unified memory: no -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94410] [radeonsi] Unreal engine 4 Segmentation fault
https://bugs.freedesktop.org/show_bug.cgi?id=94410 --- Comment #3 from Thomas Kowaliczek --- Created attachment 133122 --> https://bugs.freedesktop.org/attachment.cgi?id=133122&action=edit Schreenshot1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 94410] [radeonsi] Unreal engine 4 Segmentation fault
https://bugs.freedesktop.org/show_bug.cgi?id=94410 --- Comment #4 from Thomas Kowaliczek --- Created attachment 133123 --> https://bugs.freedesktop.org/attachment.cgi?id=133123&action=edit Screenshot2 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] drm: rcar-du: Repair vblank event handling
Hello, The recent changes to the rcar-du driver to fix a page flip handling race condition changed the order of which vblanks and page flips are handled, resulting in incorrect timestamps being reported in the vblan events. Correct this by handling vblank events in the same completion handler as page flips. Compared to v2 patch 3/4 is completely rewritten with a new approach, as the previous one caused flip timeouts for a currently unknown reason. This version now uses the vertical blanking interrupt to handle the CRTC stop race regardless of the generation of the SoC. As a result drm_atomic_helper_wait_for_vblanks() can't be used anymore to wait for completion of a page flip or CRTC disable. I've thus included the previously posted patch "drm: rcar-du: Wait for flip completion instead of vblank in commit tail" in this series. I still plan to investigate why the original version caused issues, as I believe it went in the right direction. For now this series should do, as it doesn't introduce any hack and passes all tests properly. Kieran Bingham (1): drm: rcar-du: Repair vblank for DRM page flips using the VSP Laurent Pinchart (3): drm: rcar-du: Use the VBK interrupt for vblank events drm: rcar-du: Wait for flip completion instead of vblank in commit tail drm: rcar-du: Fix race condition when disabling planes at CRTC stop drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 66 +++- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 + drivers/gpu/drm/rcar-du/rcar_du_kms.c| 2 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 8 +++- drivers/media/platform/vsp1/vsp1_drm.c | 5 ++- drivers/media/platform/vsp1/vsp1_drm.h | 2 +- drivers/media/platform/vsp1/vsp1_pipe.c | 20 +- drivers/media/platform/vsp1/vsp1_pipe.h | 2 +- drivers/media/platform/vsp1/vsp1_video.c | 6 ++- include/media/vsp1.h | 2 +- 10 files changed, 95 insertions(+), 28 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm: rcar-du: Use the VBK interrupt for vblank events
When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.
Fixes: 906eff7fcada ("drm: rcar-du: Implement support for interlaced modes")
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 98cf446391dc..17fd1cd5212c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -698,7 +698,7 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
status = rcar_du_crtc_read(rcrtc, DSSR);
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
- if (status & DSSR_FRM) {
+ if (status & DSSR_VBK) {
drm_crtc_handle_vblank(&rcrtc->crtc);
if (rcdu->info->gen < 3)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/41] drm/fsl-dcu: Use .dumb_map_offset and .dumb_destroy defaults
On 2017-07-23 12:16, Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
>
> Cc: Stefan Agner
> Cc: Alison Wang
> Signed-off-by: Noralf Trønnes
Acked-by: Stefan Agner
--
Stefan
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 5cbde19..58e9e06 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -176,8 +176,6 @@ static struct drm_driver fsl_dcu_drm_driver = {
> .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> .gem_prime_mmap = drm_gem_cma_prime_mmap,
> .dumb_create= drm_gem_cma_dumb_create,
> - .dumb_map_offset= drm_gem_cma_dumb_map_offset,
> - .dumb_destroy = drm_gem_dumb_destroy,
> .fops = &fsl_dcu_drm_fops,
> .name = "fsl-dcu-drm",
> .desc = "Freescale DCU DRM",
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm: rcar-du: Fix race condition when disabling planes at CRTC stop
When stopping the CRTC the driver must disable all planes and wait for
the change to take effect at the next vblank. Merely calling
drm_crtc_wait_one_vblank() is not enough, as the function doesn't
include any mechanism to handle the race with vblank interrupts.
Replace the drm_crtc_wait_one_vblank() call with a manual mechanism that
handles the vblank interrupt race.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 58 ++
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 8 +
2 files changed, 60 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 17fd1cd5212c..6e5bd0b92dfa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -490,23 +490,51 @@ static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
rcar_du_group_start_stop(rcrtc->group, true);
}
+static void rcar_du_crtc_disable_planes(struct rcar_du_crtc *rcrtc)
+{
+ struct rcar_du_device *rcdu = rcrtc->group->dev;
+ struct drm_crtc *crtc = &rcrtc->crtc;
+ u32 status;
+
+ /* Make sure vblank interrupts are enabled. */
+ drm_crtc_vblank_get(crtc);
+
+ /*
+* Disable planes and calculate how many vertical blanking interrupts we
+* have to wait for. If a vertical blanking interrupt has been triggered
+* but not processed yet, we don't know whether it occurred before or
+* after the planes got disabled. We thus have to wait for two vblank
+* interrupts in that case.
+*/
+ spin_lock_irq(&rcrtc->vblank_lock);
+ rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
+ status = rcar_du_crtc_read(rcrtc, DSSR);
+ rcrtc->vblank_count = status & DSSR_VBK ? 2 : 1;
+ spin_unlock_irq(&rcrtc->vblank_lock);
+
+ if (!wait_event_timeout(rcrtc->vblank_wait, rcrtc->vblank_count == 0,
+ msecs_to_jiffies(100)))
+ dev_warn(rcdu->dev, "vertical blanking timeout\n");
+
+ drm_crtc_vblank_put(crtc);
+}
+
static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
{
struct drm_crtc *crtc = &rcrtc->crtc;
/*
* Disable all planes and wait for the change to take effect. This is
-* required as the DSnPR registers are updated on vblank, and no vblank
-* will occur once the CRTC is stopped. Disabling planes when starting
-* the CRTC thus wouldn't be enough as it would start scanning out
-* immediately from old frame buffers until the next vblank.
+* required as the plane enable registers are updated on vblank, and no
+* vblank will occur once the CRTC is stopped. Disabling planes when
+* starting the CRTC thus wouldn't be enough as it would start scanning
+* out immediately from old frame buffers until the next vblank.
*
* This increases the CRTC stop delay, especially when multiple CRTCs
* are stopped in one operation as we now wait for one vblank per CRTC.
* Whether this can be improved needs to be researched.
*/
- rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
- drm_crtc_wait_one_vblank(crtc);
+ rcar_du_crtc_disable_planes(rcrtc);
/*
* Disable vertical blanking interrupt reporting. We first need to wait
@@ -695,10 +723,26 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
irqreturn_t ret = IRQ_NONE;
u32 status;
+ spin_lock(&rcrtc->vblank_lock);
+
status = rcar_du_crtc_read(rcrtc, DSSR);
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
if (status & DSSR_VBK) {
+ /*
+* Wake up the vblank wait if the counter reaches 0. This must
+* be protected by the vblank_lock to avoid races in
+* rcar_du_crtc_disable_planes().
+*/
+ if (rcrtc->vblank_count) {
+ if (--rcrtc->vblank_count == 0)
+ wake_up(&rcrtc->vblank_wait);
+ }
+ }
+
+ spin_unlock(&rcrtc->vblank_lock);
+
+ if (status & DSSR_VBK) {
drm_crtc_handle_vblank(&rcrtc->crtc);
if (rcdu->info->gen < 3)
@@ -756,6 +800,8 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int index)
}
init_waitqueue_head(&rcrtc->flip_wait);
+ init_waitqueue_head(&rcrtc->vblank_wait);
+ spin_lock_init(&rcrtc->vblank_lock);
rcrtc->group = rgrp;
rcrtc->mmio_offset = mmio_offsets[index];
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 3cc376826592..065b91f5b1d9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -15,6 +15,7 @@
#define __RCAR_DU_CRTC_H__
#include
+
Re: [PATCH] tinydrm: repaper: add CONFIG_THERMAL dependency
Den 27.07.2017 11.58, skrev Arnd Bergmann:
The new RePaper driver uses the thermal subsystem, and fails to link
when it is built-in but thermal is a loadable module:
drivers/gpu/drm/tinydrm/repaper.o: In function `repaper_probe':
repaper.c:(.text+0x540): undefined reference to `thermal_zone_get_zone_by_name'
drivers/gpu/drm/tinydrm/repaper.o: In function `repaper_fb_dirty':
repaper.c:(.text+0xff4): undefined reference to `thermal_zone_get_temp'
This adds another Kconfig dependency to prevent the broken configuration,
forcing repaper to be a module too.
Fixes: 3589211e9b03 ("drm/tinydrm: Add RePaper e-ink driver")
Signed-off-by: Arnd Bergmann
---
Thanks for fixing this, applied to drm-misc.
Noralf.
drivers/gpu/drm/tinydrm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 9596e447f877..f17c3caceab2 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -23,6 +23,7 @@ config TINYDRM_MI0283QT
config TINYDRM_REPAPER
tristate "DRM support for Pervasive Displays RePaper panels (V231)"
depends on DRM_TINYDRM && SPI
+ depends on THERMAL || !THERMAL
help
DRM driver for the following Pervasive Displays panels:
1.44" TFT EPD Panel (E1144CS021)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm: rcar-du: Wait for flip completion instead of vblank in commit tail
Page flips can take more than one vertical blanking to complete if
arming the page flips races with the vertical blanking interrupt.
Waiting for one vblank to complete the atomic commit in the commit tail
handler is thus incorrect, and can lead to framebuffers being released
while still being scanned out.
Fix this by waiting for flip completion instead, using the
drm_atomic_helper_wait_for_flip_done() helper.
Fixes: 0d230422d256 ("drm: rcar-du: Register a completion callback with VSP1")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b91257dee98f..221e22922396 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -262,7 +262,7 @@ static void rcar_du_atomic_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_modeset_enables(dev, old_state);
drm_atomic_helper_commit_hw_done(old_state);
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
+ drm_atomic_helper_wait_for_flip_done(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] selftests: sync: add test that closes the fd before fence signal
From: Gustavo Padovan
We found this bug in the sw_sync so adding a test case to prevent it to
happen in the future.
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Gustavo Padovan
---
To be applied after the TAP13 convertion patches.
---
tools/testing/selftests/sync/sync_fence.c | 23 +++
tools/testing/selftests/sync/sync_test.c | 1 +
tools/testing/selftests/sync/synctest.h | 1 +
3 files changed, 25 insertions(+)
diff --git a/tools/testing/selftests/sync/sync_fence.c
b/tools/testing/selftests/sync/sync_fence.c
index 13f1752..70cfa61 100644
--- a/tools/testing/selftests/sync/sync_fence.c
+++ b/tools/testing/selftests/sync/sync_fence.c
@@ -29,6 +29,29 @@
#include "sw_sync.h"
#include "synctest.h"
+int test_close_fence_fd_before_inc(void)
+{
+ int fence, valid, ret;
+ int timeline = sw_sync_timeline_create();
+
+ valid = sw_sync_timeline_is_valid(timeline);
+ ASSERT(valid, "Failure allocating timeline\n");
+
+ fence = sw_sync_fence_create(timeline, "allocFence", 1);
+ valid = sw_sync_fence_is_valid(fence);
+ ASSERT(valid, "Failure allocating fence\n");
+
+ sw_sync_fence_destroy(fence);
+
+ /* Advance timeline from 0 -> 1 */
+ ret = sw_sync_timeline_inc(timeline, 1);
+ ASSERT(ret == 0, "Failure advancing timeline\n");
+
+ sw_sync_timeline_destroy(timeline);
+
+ return 0;
+}
+
int test_fence_one_timeline_wait(void)
{
int fence, valid, ret;
diff --git a/tools/testing/selftests/sync/sync_test.c
b/tools/testing/selftests/sync/sync_test.c
index 7f79382..2f73ace 100644
--- a/tools/testing/selftests/sync/sync_test.c
+++ b/tools/testing/selftests/sync/sync_test.c
@@ -95,6 +95,7 @@ int main(void)
RUN_TEST(test_alloc_fence);
RUN_TEST(test_alloc_fence_negative);
+ RUN_TEST(test_close_fence_fd_before_inc);
RUN_TEST(test_fence_one_timeline_wait);
RUN_TEST(test_fence_one_timeline_merge);
RUN_TEST(test_fence_merge_same_fence);
diff --git a/tools/testing/selftests/sync/synctest.h
b/tools/testing/selftests/sync/synctest.h
index 90a8e53..86a9532 100644
--- a/tools/testing/selftests/sync/synctest.h
+++ b/tools/testing/selftests/sync/synctest.h
@@ -46,6 +46,7 @@ int test_alloc_fence(void);
int test_alloc_fence_negative(void);
/* Fence tests with one timeline */
+int test_close_fence_fd_before_inc(void);
int test_fence_one_timeline_wait(void);
int test_fence_one_timeline_merge(void);
--
2.9.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] drm/rcar-du: Use new iterator macros, v2.
Hi Maarten, On Wednesday 26 Jul 2017 14:53:33 Laurent Pinchart wrote: > On Wednesday 19 Jul 2017 16:39:16 Maarten Lankhorst wrote: > > for_each_obj_in_state is about to be removed, so use the correct new > > iterator macros. > > > > Also look at new_plane_state instead of plane->state when looking up > > the hw planes in use. They should be the same except when reallocating, > > (in which case this code is skipped) and we should really stop looking > > at obj->state whenever possible. > > > > Changes since v1: > > - Actually compile correctly. > > > > Signed-off-by: Maarten Lankhorst > > Cc: Laurent Pinchart > > Cc: linux-renesas-...@vger.kernel.org I plan to send a pull request to Dave in the middle of next week with a bunch of rcar-du-drm patches that will generate a few conflicts with this one. They're all simple to solve as they're located in comments, but that will be annoying nonetheless. I can include a rebased version of this patch in my pull request if it can help, depending on when you plan to get this series merged in drm-misc-next. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101631] [amd-staging] RX480 system hang; spamming errors (dc_surface)
https://bugs.freedesktop.org/show_bug.cgi?id=101631 Denys changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Denys --- Looks like everything is fine now (65168ffe667585ba22a7e111bd18199d02e16d70) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101484] [regression, bisected] Steam fails to render content, if mesa is compiled with -O2 -march=haswell
https://bugs.freedesktop.org/show_bug.cgi?id=101484 Lucas Francesco changed: What|Removed |Added CC||lucas.francesc...@gmail.com --- Comment #15 from Lucas Francesco --- Created attachment 133133 --> https://bugs.freedesktop.org/attachment.cgi?id=133133&action=edit lolscren this happens on LoL using nine too(and probably other games using nine with wine), but setting -nobmi as flag make every game that uses nine to not launch. do we have any hints about what part of the new code is causing this bug? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/41] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy
Den 23.07.2017 21.16, skrev Noralf Trønnes: This adds defaults for the drm_driver.dumb_destroy and drm_driver.dumb_map_offset callbacks as discussed with Daniel. vmwgfx is the only driver that doesn't use drm_gem_dumb_destroy(). vgem vgem changes behaviour after this, because it didn't have .dumb_destroy set, something the docs mandates. This patchset is part of a process to add a shmem gem library like the cma library. The common parts between the two goes into core or helpers. Noralf. Thanks for reviews and testing. The first batch is applied to drm-misc-next: [01/41] drm/gem: Add drm_gem_dumb_map_offset() [02/41] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy [03/41] drm/arc: Use .dumb_map_offset and .dumb_destroy defaults [04/41] drm/arm: hdlcd: Use .dumb_map_offset and .dumb_destroy defaults [05/41] drm/arm: mali-dp: Use .dumb_map_offset and .dumb_destroy defaults [06/41] drm/atmel-hlcdc: Use .dumb_map_offset and .dumb_destroy defaults [09/41] drm/imx: Use .dumb_map_offset and .dumb_destroy defaults [12/41] drm/pl111: Use .dumb_map_offset and .dumb_destroy defaults [13/41] drm/rcar-du: Use .dumb_map_offset and .dumb_destroy defaults [14/41] drm/shmobile: Use .dumb_map_offset and .dumb_destroy defaults [16/41] drm/stm: Use .dumb_map_offset and .dumb_destroy defaults [17/41] drm/sun4i: Use .dumb_map_offset and .dumb_destroy defaults [18/41] drm/tilcdc: Use .dumb_map_offset and .dumb_destroy defaults [19/41] drm/vc4: Use .dumb_map_offset and .dumb_destroy defaults [20/41] drm/zte: Use .dumb_map_offset and .dumb_destroy defaults [21/41] drm/tinydrm: Use .dumb_map_offset and .dumb_destroy defaults [22/41] drm/mediatek: Use .dumb_map_offset and .dumb_destroy defaults [24/41] drm/rockchip: Use .dumb_map_offset and .dumb_destroy defaults [29/41] drm/amdgpu: Use the drm_driver.dumb_destroy default [30/41] drm/omapdrm: Use the drm_driver.dumb_destroy default [32/41] drm/nouveau: Use the drm_driver.dumb_destroy default [36/41] drm/hisilicon: hibmc: Use the drm_driver.dumb_destroy default Noralf Trønnes (41): drm/gem: Add drm_gem_dumb_map_offset() drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy drm/arc: Use .dumb_map_offset and .dumb_destroy defaults drm/arm: hdlcd: Use .dumb_map_offset and .dumb_destroy defaults drm/arm: mali-dp: Use .dumb_map_offset and .dumb_destroy defaults drm/atmel-hlcdc: Use .dumb_map_offset and .dumb_destroy defaults drm/fsl-dcu: Use .dumb_map_offset and .dumb_destroy defaults drm/kirin: Use .dumb_map_offset and .dumb_destroy defaults drm/imx: Use .dumb_map_offset and .dumb_destroy defaults drm/meson: Use .dumb_map_offset and .dumb_destroy defaults drm/mxsfb: Use .dumb_map_offset and .dumb_destroy defaults drm/pl111: Use .dumb_map_offset and .dumb_destroy defaults drm/rcar-du: Use .dumb_map_offset and .dumb_destroy defaults drm/shmobile: Use .dumb_map_offset and .dumb_destroy defaults drm/sti: Use .dumb_map_offset and .dumb_destroy defaults drm/stm: Use .dumb_map_offset and .dumb_destroy defaults drm/sun4i: Use .dumb_map_offset and .dumb_destroy defaults drm/tilcdc: Use .dumb_map_offset and .dumb_destroy defaults drm/vc4: Use .dumb_map_offset and .dumb_destroy defaults drm/zte: Use .dumb_map_offset and .dumb_destroy defaults drm/tinydrm: Use .dumb_map_offset and .dumb_destroy defaults drm/mediatek: Use .dumb_map_offset and .dumb_destroy defaults drm/gma500: Use .dumb_map_offset and .dumb_destroy defaults drm/rockchip: Use .dumb_map_offset and .dumb_destroy defaults drm/tegra: Use .dumb_map_offset and .dumb_destroy defaults drm/cirrus: Use the drm_driver.dumb_destroy default drm/udl: Use the drm_driver.dumb_destroy default drm/qxl: Use the drm_driver.dumb_destroy default drm/amdgpu: Use the drm_driver.dumb_destroy default drm/omapdrm: Use the drm_driver.dumb_destroy default drm/ast: Use the drm_driver.dumb_destroy default drm/nouveau: Use the drm_driver.dumb_destroy default drm/i915: Use the drm_driver.dumb_destroy default drm/msm: Use the drm_driver.dumb_destroy default drm/exynos: Use the drm_driver.dumb_destroy default drm/hisilicon: hibmc: Use the drm_driver.dumb_destroy default drm/mgag200: Use the drm_driver.dumb_destroy default drm/radeon: Use the drm_driver.dumb_destroy default drm/bochs: Use the drm_driver.dumb_destroy default drm/armada: Use the drm_driver.dumb_destroy default drm/virtio: Use the drm_driver.dumb_destroy default drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 - drivers/gpu/drm/arc/arcpgu_drv.c| 2 -- drivers/gpu/drm/arm/hdlcd_drv.c | 2 -- drivers/gpu/drm/arm/malidp_drv.c| 2 -- drivers/gpu/drm/armada/armada_drv.c | 1 - drivers/gpu/drm/armada/armada_gem.c | 6 - drivers/gpu/drm/armada/armada_gem.h | 2 -- drivers/gpu/drm/ast/ast_drv.c | 1 - drivers/
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #20 from Robin --- Created attachment 133132 --> https://bugs.freedesktop.org/attachment.cgi?id=133132&action=edit Brute-force fix, resets sdma every init After much trial and error, I've found this approach to work. Every hw_init both sDMA's will be flagged for a soft reset. I have tried the existing soft reset code as well, but the busy status flags that are being used to selectively reset the sDMA's do not work reliably in my tests to prevent the errors. Using this patch the 9 and 10 ring test errors no longer appear and prevents the ring 1 errors. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101881] [regression] 32bit steam games segfault when launched with DRI_PRIME=1
https://bugs.freedesktop.org/show_bug.cgi?id=101881
--- Comment #5 from Rafael Ristovski ---
I can confirm a very similar issue on my SI Cape Verde (HD8850M GCN1.0) using
the amdgpu driver with mesa. It happens even if I compile mesa's `xdemos` with
-m32 in which case most of the binaries produce a segfault pointing to
drmGetVersion().
Can you confirm the same thing on your end?
Steps to reproduce:
1) Compile xdemos with -m32
2) Load `glthreads` in gdb
3) Switch DRI on inside gdb via 'set environment DRI_prime=1'
4) After you run the program ('r'), and it segfaults, try and see what 'bt'
produces.
For me its the following:
#0 0xf7a9c001 in ?? () from /lib32/libc.so.6
#1 0xf7a9bceb in strdup () from /lib32/libc.so.6
#2 0xf7735c55 in drmGetVersion () from /usr/lib32/libdrm.so.2
#3 0xf71a1acc in amdgpu_winsys_create () from /usr/lib32/dri/radeonsi_dri.so
#4 0xf69152d8 in ?? () from /usr/lib32/dri/radeonsi_dri.so
#5 0xf6de8238 in ?? () from /usr/lib32/dri/radeonsi_dri.so
#6 0xf6de2eb3 in ?? () from /usr/lib32/dri/radeonsi_dri.so
#7 0xf7e0f0c5 in ?? () from /usr/lib32/libGL.so.1
#8 0xf7de040c in ?? () from /usr/lib32/libGL.so.1
#9 0xf7dde789 in glXChooseVisual () from /usr/lib32/libGL.so.1
#10 0x0804a483 in create_window ()
#11 0x0804abe9 in main ()
Note 64bit binaries work flawlessly.
Using gcc 8 alpha here.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dma-buf/sw_sync: move timeline_fence_ops around
From: Gustavo Padovan
We are going to use timeline_fence_signaled() in a internal function in
the next commit.
Cc: Chris Wilson
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 138 +++---
1 file changed, 69 insertions(+), 69 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index af1bc84..ef0cc08 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -125,6 +125,75 @@ static void sync_timeline_put(struct sync_timeline *obj)
kref_put(&obj->kref, sync_timeline_free);
}
+static const char *timeline_fence_get_driver_name(struct dma_fence *fence)
+{
+ return "sw_sync";
+}
+
+static const char *timeline_fence_get_timeline_name(struct dma_fence *fence)
+{
+ struct sync_timeline *parent = dma_fence_parent(fence);
+
+ return parent->name;
+}
+
+static void timeline_fence_release(struct dma_fence *fence)
+{
+ struct sync_pt *pt = dma_fence_to_sync_pt(fence);
+ struct sync_timeline *parent = dma_fence_parent(fence);
+
+ if (!list_empty(&pt->link)) {
+ unsigned long flags;
+
+ spin_lock_irqsave(fence->lock, flags);
+ if (!list_empty(&pt->link)) {
+ list_del(&pt->link);
+ rb_erase(&pt->node, &parent->pt_tree);
+ }
+ spin_unlock_irqrestore(fence->lock, flags);
+ }
+
+ sync_timeline_put(parent);
+ dma_fence_free(fence);
+}
+
+static bool timeline_fence_signaled(struct dma_fence *fence)
+{
+ struct sync_timeline *parent = dma_fence_parent(fence);
+
+ return !__dma_fence_is_later(fence->seqno, parent->value);
+}
+
+static bool timeline_fence_enable_signaling(struct dma_fence *fence)
+{
+ return true;
+}
+
+static void timeline_fence_value_str(struct dma_fence *fence,
+ char *str, int size)
+{
+ snprintf(str, size, "%d", fence->seqno);
+}
+
+static void timeline_fence_timeline_value_str(struct dma_fence *fence,
+char *str, int size)
+{
+ struct sync_timeline *parent = dma_fence_parent(fence);
+
+ snprintf(str, size, "%d", parent->value);
+}
+
+static const struct dma_fence_ops timeline_fence_ops = {
+ .get_driver_name = timeline_fence_get_driver_name,
+ .get_timeline_name = timeline_fence_get_timeline_name,
+ .enable_signaling = timeline_fence_enable_signaling,
+ .signaled = timeline_fence_signaled,
+ .wait = dma_fence_default_wait,
+ .release = timeline_fence_release,
+ .fence_value_str = timeline_fence_value_str,
+ .timeline_value_str = timeline_fence_timeline_value_str,
+};
+
/**
* sync_timeline_signal() - signal a status change on a sync_timeline
* @obj: sync_timeline to signal
@@ -216,75 +285,6 @@ static struct sync_pt *sync_pt_create(struct sync_timeline
*obj,
return pt;
}
-static const char *timeline_fence_get_driver_name(struct dma_fence *fence)
-{
- return "sw_sync";
-}
-
-static const char *timeline_fence_get_timeline_name(struct dma_fence *fence)
-{
- struct sync_timeline *parent = dma_fence_parent(fence);
-
- return parent->name;
-}
-
-static void timeline_fence_release(struct dma_fence *fence)
-{
- struct sync_pt *pt = dma_fence_to_sync_pt(fence);
- struct sync_timeline *parent = dma_fence_parent(fence);
-
- if (!list_empty(&pt->link)) {
- unsigned long flags;
-
- spin_lock_irqsave(fence->lock, flags);
- if (!list_empty(&pt->link)) {
- list_del(&pt->link);
- rb_erase(&pt->node, &parent->pt_tree);
- }
- spin_unlock_irqrestore(fence->lock, flags);
- }
-
- sync_timeline_put(parent);
- dma_fence_free(fence);
-}
-
-static bool timeline_fence_signaled(struct dma_fence *fence)
-{
- struct sync_timeline *parent = dma_fence_parent(fence);
-
- return !__dma_fence_is_later(fence->seqno, parent->value);
-}
-
-static bool timeline_fence_enable_signaling(struct dma_fence *fence)
-{
- return true;
-}
-
-static void timeline_fence_value_str(struct dma_fence *fence,
- char *str, int size)
-{
- snprintf(str, size, "%d", fence->seqno);
-}
-
-static void timeline_fence_timeline_value_str(struct dma_fence *fence,
-char *str, int size)
-{
- struct sync_timeline *parent = dma_fence_parent(fence);
-
- snprintf(str, size, "%d", parent->value);
-}
-
-static const struct dma_fence_ops timeline_fence_ops = {
- .get_driver_name = timeline_fence_get_driver_name,
- .get_timeline_name = timeline_fence_get_timeline_name,
- .enable_signaling = timeline_fence_enable_signaling,
- .signaled = timeline_fence_signaled,
- .wait = dma_fence_default_wait,
- .release = timeli
Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers
On Fri, Jul 28, 2017 at 2:13 AM, Christian König
wrote:
> Am 28.07.2017 um 03:43 schrieb Alex Deucher:
>>
>> On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote:
>>>
>>> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use
>>> designated initializers") mark other tableFunction entries with
>>> designated
>>> initializers. The randstruct plugin requires designated initializers for
>>> structures that are entirely function pointers.
>>>
>>> Cc: Rex Zhu
>>> Cc: Hawking Zhang
>>> Cc: Alex Deucher
>>> Signed-off-by: Kees Cook
>>> ---
>>> If I can get an Ack for this, I'll carry it in the gcc-plugins tree,
>>> unless
>>> you think this is worth landing for v4.13, in which case, please take it
>>> now. :)
>>>
>> Acked-by: Alex Deucher
>>
>> I'm happy to take this through my tree if that is ok with you.
>
>
> I'm wondering a bit how the plugin detects that it can randomize a structure
> layout?
>
> We have a couple of structs where this would be fatal.
Automatic randomization only happen on struct that are entirely
function pointers.
See:
https://git.kernel.org/linus/313dd1b629219db50cad532dba6a3b3b22ffe622
And:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?id=914e2dfc61195a95868ae5c750690a7f1c87bc66
If you have any structures that are shared externally from the kernel,
I can mark them with __no_randomize_layout.
-Kees
--
Kees Cook
Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: adding SDI to drm_connector_enum_list
Hi Daniel,
Thanks for your reply.
Currently I am using connector type 'Unknown' , and functionally it serves my
need.
Intention for sending this patch is that userspace tools should recognize SDI
drivers as SDI only.
Also, I see there are number of 'SDI' drivers getting developed 'under the
hood' in linux kernel.
This patch will benefit all of them.
It will be great if you could consider it.
Regards,
Saurabh
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, July 26, 2017 8:08 PM
To: Saurabh Singh
Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
airl...@linux.ie; Saurabh Singh ; Dinesh Kumar
Subject: Re: [PATCH] drm: adding SDI to drm_connector_enum_list
On Wed, Jul 26, 2017 at 10:22:49AM +0530, Saurabh Sengar wrote:
> adding SDI to drm connector list
>
> Signed-off-by: Saurabh Sengar
This is an uapi change, i.e. userspace needs to be updated. Do you _really_
need this? I'd recommend to just use something existing (go with VIRTUAL maybe,
not sure).
Either way, needs to come together with the actual users and userspace side
patches. If you really want this.
-Daniel
> ---
> drivers/gpu/drm/drm_connector.c | 1 +
> include/uapi/drm/drm_mode.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c index 2db7fb5..ea48ddb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -86,6 +86,7 @@ static struct drm_conn_prop_enum_list
> drm_connector_enum_list[] = {
> { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
> { DRM_MODE_CONNECTOR_DSI, "DSI" },
> { DRM_MODE_CONNECTOR_DPI, "DPI" },
> + { DRM_MODE_CONNECTOR_SDI, "SDI" },
> };
>
> void drm_connector_ida_init(void)
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index df0e350..9b8d204 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -247,6 +247,7 @@ struct drm_mode_get_encoder {
> #define DRM_MODE_CONNECTOR_VIRTUAL 15
> #define DRM_MODE_CONNECTOR_DSI 16
> #define DRM_MODE_CONNECTOR_DPI 17
> +#define DRM_MODE_CONNECTOR_SDI 18
>
> struct drm_mode_get_connector {
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #19 from Robin --- I've found that my test cases only trigger the PCI drivers' amdgpu_pci_remove and amdgpu_pci_probe functions. Adding the new shutdown function call amdgpu_device_shutdown(adev); to the amdgpu_pci_remove function does not resolve the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/7] drm/stm: ltdc: Fix leak of px clk enable in some error paths
Hi Philippe,
On 07/17/2017 01:10 PM, Philippe CORNU wrote:
The pixel clock gets enabled early during init, since it's required
in order to read registers. This pixel clock must be disabled if
errors during this init phase.
This patch was pulled in to drm-misc-next, but it lacks your Sign-off.
It looks like the Ack and the Sign-off got accidentally mixed up
Can you please reply to this mail with your "Signed-off-by" so that
we have proof of it on dri-devel?
Thanks,
Archit
Signed-off-by: Eric Anholt
Acked-by: Philippe Cornu
---
drivers/gpu/drm/stm/ltdc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5331760..7f64d5a 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1045,13 +1045,15 @@ int ltdc_load(struct drm_device *ddev)
if (of_address_to_resource(np, 0, &res)) {
DRM_ERROR("Unable to get resource\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto err;
}
ldev->regs = devm_ioremap_resource(dev, &res);
if (IS_ERR(ldev->regs)) {
DRM_ERROR("Unable to get ltdc registers\n");
- return PTR_ERR(ldev->regs);
+ ret = PTR_ERR(ldev->regs);
+ goto err;
}
for (i = 0; i < MAX_IRQ; i++) {
@@ -1064,7 +1066,7 @@ int ltdc_load(struct drm_device *ddev)
dev_name(dev), ddev);
if (ret) {
DRM_ERROR("Failed to register LTDC interrupt\n");
- return ret;
+ goto err;
}
}
@@ -1079,7 +1081,7 @@ int ltdc_load(struct drm_device *ddev)
if (ret) {
DRM_ERROR("hardware identifier (0x%08x) not supported!\n",
ldev->caps.hw_version);
- return ret;
+ goto err;
}
DRM_INFO("ltdc hw version 0x%08x - ready\n", ldev->caps.hw_version);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/i915: Add support for CCS modifiers
On 17-07-29 13:53:10, Daniel Stone wrote:
Hi Ben,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
+ } else if (INTEL_GEN(dev_priv) >= 9) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
- modifiers = skl_format_modifiers;
+ if (pipe >= PIPE_C)
+ modifiers = skl_format_modifiers_ccs;
+ else
+ modifiers = skl_format_modifiers_noccs;
Shouldn't that be (pipe < PIPE_C)?
Cheers,
Daniel
Yep. It was wrong in v7 too :/. I have it fixed locally.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 410/417] htmldocs: include/linux/sync_file.h:51: warning: No description found for parameter 'flags'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 9394a345b337d38d55ff027f25147c3a7360d320 commit: db1fc97ca0c0d3fdeeadf314d99a26188438940a [410/417] dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/init.h:1: warning: no structured comments found include/linux/mod_devicetable.h:687: warning: Excess struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id' include/linux/mod_devicetable.h:687: warning: Excess struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id' kernel/sched/core.c:2080: warning: No description found for parameter 'rf' kernel/sched/core.c:2080: warning: Excess function parameter 'cookie' description in 'try_to_wake_up_local' include/linux/wait.h:555: warning: No description found for parameter 'wq' include/linux/wait.h:555: warning: Excess function parameter 'wq_head' description in 'wait_event_interruptible_hrtimeout' include/linux/wait.h:759: warning: No description found for parameter 'wq_head' include/linux/wait.h:759: warning: Excess function parameter 'wq' description in 'wait_event_killable' include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found include/linux/device.h:968: warning: No description found for parameter 'dma_ops' drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found >> include/linux/sync_file.h:51: warning: No description found for parameter >> 'flags' include/linux/iio/iio.h:603: warning: No description found for parameter 'trig_readonly' include/linux/iio/trigger.h:151: warning: No description found for parameter 'indio_dev' include/linux/iio/trigger.h:151: warning: No description found for parameter 'trig' include/linux/device.h:969: warning: No description found for parameter 'dma_ops' drivers/ata/libata-eh.c:1449: warning: No description found for parameter 'link' drivers/ata/libata-eh.c:1449: warning: Excess function parameter 'ap' description in 'ata_eh_done' drivers/ata/libata-eh.c:1590: warning: No description found for parameter 'qc' drivers/ata/libata-eh.c:1590: warning: Excess function parameter 'dev' description in 'ata_eh_request_sense' drivers/mtd/nand/nand_base.c:2751: warning: Excess function parameter 'cached' description in 'nand_write_page' drivers/mtd/nand/nand_base.c:2751: warning: Excess function parameter 'cached' description in 'nand_write_page' arch/s390/include/asm/cmb.h:1: warning: no structured comments found drivers/scsi/scsi_lib.c:1116: warning: No description found for parameter 'rq' drivers/scsi/constants.c:1: warning: no structured comments found include/linux/usb/gadget.h:230: warning: No description found for parameter 'claimed' include/linux/usb/gadget.h:230: warning: No description found for parameter 'enabled' include/linux/usb/gadget.h:412: warning: No description found for parameter 'quirk_altset_not_supp' include/linux/usb/gadget.h:412: warning: No description found for parameter 'quirk_stall_not_supp' include/linux/usb/gadget.h:412: warning: No description found for parameter 'quirk_zlp_not_supp' fs/inode.c:1666: warning: No description found for parameter 'rcu' include/linux/jbd2.h:443: warning: No description found for parameter 'i_transaction' include/linux/jbd2.h:443: warning: No description found for parameter 'i_next_transaction' include/linux/jbd2.h:443: warning: No description found for parameter 'i_list' include/linux/jbd2.h:443: warning: No description found for parameter 'i_vfs_inode' include/linux/jbd2.h:443: warning: No description found for parameter 'i_flags' include/linux/jbd2.h:497: warning: No description found for parameter 'h_rsv_handle' include/linux/jbd2.h:497: warning: No description found for parameter 'h_reserved' include/linux/jbd2.h:497: warning: No description found for parameter 'h_type' include/linux/jbd2.h:497: warning: No description found for parameter 'h_line_no' include/linux/jbd2.h:497: warning: No description found for parameter 'h_start_jiffies' include/linux/jbd2.h:497: warning: No description found for parameter 'h_requested_credits' include/linux/jbd2.h:497: warning: No description found for parameter 'saved_alloc_context' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_chkpt_bhs' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_devname' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_average_commit_time' include/linux/jbd2.h:1050: warning: No description found for parameter 'j_min_batch_time' include/linux/jbd2.h:1050: warning: No descriptio
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #80 from Jean Delvare (jdelv...@suse.de) --- I tested the patch from comment #78 and unfortunately I have to report that it doesn't fix the problem for me, checkerboard effect is still present. Nevertheless these cleanups look good so I think they should go upstream, assuming they don't break anything else. I have noticed that the values of VERDE_GB_ADDR_CONFIG_GOLDEN and HAINAN_GB_ADDR_CONFIG_GOLDEN which were kept do not match the ones in the radeon driver. I tried using the ones from the radeon driver instead but it did not help. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
