Re: Compiler warnings with current amd-staging-drm-next

2019-05-16 Thread Michel Dänzer
On 2019-05-10 1:17 p.m., Michel Dänzer wrote: > > drivers/gpu/drm//amd/amdgpu/df_v3_6.c: In function ‘df_v3_6_pmc_start’: > drivers/gpu/drm//amd/amdgpu/df_v3_6.c:482:9: warning: ‘ret’ may be used > uninitialized in this function [-Wmaybe-uninitialized] &g

Re: [PATCH] Revert "vgaarb: Keep adding VGA device in queue"

2019-05-13 Thread Michel Dänzer
On 2019-05-10 8:01 p.m., Aaron Ma wrote: > On 5/10/19 11:46 PM, Michel Dänzer wrote: >>> Given that the bug is a bit a mess I think we need to add a bit more >>> context here in the commit message. My understanding: >>> >>> Goal of the revert commit

Re: [PATCH] Revert "vgaarb: Keep adding VGA device in queue"

2019-05-10 Thread Michel Dänzer
. It's not clear to me yet that their expectation of Xorg to pick any particular one of them without configuration was justified. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer __

Re: [PATCH] Revert "vgaarb: Keep adding VGA device in queue"

2019-05-10 Thread Michel Dänzer
they show why Xorg picks one card or the other in each case. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.fre

Compiler warnings with current amd-staging-drm-next

2019-05-10 Thread Michel Dänzer
pmc_start’: drivers/gpu/drm//amd/amdgpu/df_v3_6.c:482:9: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] return ret; ^~~ -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | M

[PATCH xf86-video-ati] dri3: Always flush glamor before sharing pixmap storage with clients

2019-05-09 Thread Michel Dänzer
From: Michel Dänzer Even if glamor_gbm_bo_from_pixmap / glamor_fd_from_pixmap themselves don't trigger any drawing, there could already be unflushed drawing to the pixmap whose storage we share with a client. (Ported from amdgpu commit 4b17533fcb30842caf0035ba593b7d986520cc85) Signed-off

Re: [PATCH] drm/amd/display: Allow faking displays as VRR capable.

2019-04-30 Thread Michel Dänzer
e another knob to break things, resulting in support burden for us. How about e.g. making the vrr_capable property mutable, or adding another property for this? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: enable separate timeout setting for every ring type

2019-04-29 Thread Michel Dänzer
timeout = 1; This is a bit weird formatting. :) Maybe it can be one or two lines, otherwise the second continuation line should have the same indentation as the first one. > + /* Enforce no timeout on compute job at default */ "by default" (same in amdgpu_fence_driver_init_

Re: [PATCH] drm/amdgpu: support gpu recovery tests on compute rings

2019-04-26 Thread Michel Dänzer
, e.g. amdgpu.lockup_timeout=1,0 The first value would need to have the same meaning as now for backwards compatibility. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer _

[PATCH xf86-video-ati] Retry get_fb_ptr in get_fb

2019-04-24 Thread Michel Dänzer
From: Michel Dänzer If get_fb_ptr returns NULL, try again after pixmap_get_handle, it should work then. Fixes spurious Present page flipping failures using "normal" pixmaps which aren't shared with direct rendering clients, e.g. with a compositor using the RENDER extension. Bugzi

Re: Improvements to VRR below-the-range/low framerate compensation.

2019-04-18 Thread Michel Dänzer
pensation mechanisms such as those touched by this series, since userspace can call into the kernel ahead of the target time, giving the kernel an opportunity to make adjustments earlier. Since you have a strong use-case for this functionality, maybe you'd be interested in working on

Re: [PATCH] drm/amd/display: Expose support for DRM_FORMAT_RGB565

2019-04-15 Thread Michel Dänzer
t overlay_formats[] = { > Could DRM_FORMAT_ARGB1555 / DRM_FORMAT_C8 be supported as well? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx

Re: [PATCH] drm/amdgpu: use pcie_bandwidth_available rather than open coding it

2019-04-11 Thread Michel Dänzer
u_device_get_min_pci_speed_width(adev, _speed_cap, > - _link_width); > + pcie_bandwidth_available(adev->pdev, NULL, > + _speed_cap, _link_width); > > if (adev-&g

Re: [PATCH 1/2] drm/ttm: fix out-of-bounds read in ttm_put_pages() v2

2019-04-08 Thread Michel Dänzer
,7 @@ static void ttm_put_pages(struct page **pages, unsigned > npages, int flags, > unsigned max_size, n2free; > > spin_lock_irqsave(>lock, irq_flags); > - while (i < npages) { > + while ((npages - i) >= HPAGE_PMD_NR) { >

Re: Screen flicckering due to "drm/amdgpu: enable gfxoff again on raven series"

2019-04-08 Thread Michel Dänzer
On 2019-04-05 10:00 p.m., Pinky wrote: > [...] terminal in X sometimes display black instead of text when > scrooling. Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=110214 ? -- Earthling Michel Dänzer | https://www.amd.com Libre software enth

Re: [PATCH xf86-video-amdgpu] Allow changing DCC parameters between flips

2019-04-03 Thread Michel Dänzer
ead only allowing the DCC parameters to change with DRM minor version >= 31 as well. Thanks for this patch anyway! -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X dev

Re: [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4

2019-03-28 Thread Michel Dänzer
(prev && prev->seqno >= point); >> >> >> I think the WARN/BUG macros should only fire when there is an issue >> with programming from within the kernel. >> >> But this particular warning can be trigge

Re: [PATCH] drm/amdgpu: don't put the root PD into the relocated list

2019-03-27 Thread Michel Dänzer
o submit a zero sized IB to the SDMA. > > Signed-off-by: Christian König Tested-by: Michel Dänzer -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer __

Re: WARNING at amdgpu_vm_sdma.c:85

2019-03-27 Thread Michel Dänzer
t I attached shows that SDMA hangs afterwards, so it's not harmless. :) -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx ma

Re: WARNING at amdgpu_vm_sdma.c:85

2019-03-26 Thread Michel Dänzer
On 2019-03-26 4:21 p.m., Michel Dänzer wrote: > > I'm hitting some badness with piglit today, see the attached dmesg > excerpt. I was away for a couple of days, but looks like it might be > related to the VM changes? I'll try bisecting. Bisected to: 602b5050d839c40572bbb19e9b17

WARNING at amdgpu_vm_sdma.c:85

2019-03-26 Thread Michel Dänzer
I'm hitting some badness with piglit today, see the attached dmesg excerpt. I was away for a couple of days, but looks like it might be related to the VM changes? I'll try bisecting. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast

Re: [PATCH v2] gpu: radeon: fix a potential NULL-pointer dereference

2019-03-26 Thread Michel Dänzer
On 2019-03-25 10:05 p.m., Kangjie Lu wrote: > In case alloc_workqueue fails, the fix frees memory and > returns -ENOMEM to avoid potential NULL pointer dereference. > > Signed-off-by: Kangjie Lu > --- > v2: use radeon_crtc_destroy to properly clean up resources as > sugge

Re: [PATCH] gpu: radeon: fix a potential NULL-pointer dereference

2019-03-25 Thread Michel Dänzer
this case and for radeon_modeset_init to propagate that, which will prevent the driver as a whole from initializing. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer __

[ANNOUNCE] xf86-video-amdgpu 19.0.1

2019-03-19 Thread Michel Dänzer
, allowing monitors using DisplayPort Multi Stream Transport tiling to work better out of the box. Thanks to everybody who contributed to this release in any way! Dave Airlie (1): modesetting: add tile property support Michel Dänzer (1): Bump version for the 19.0.1 release git tag

[ANNOUNCE] xf86-video-ati 19.0.1

2019-03-19 Thread Michel Dänzer
contributed to this release in any way! Dave Airlie (1): modesetting: add tile property support Michel Dänzer (3): Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows" Use radeon_finish in drmmode_crtc_scanout_update Bump version for 19.0.1 release git

Re: Input lag bug in programs like Blender

2019-03-19 Thread Michel Dänzer
led. The above disables that, which probably works around a blender issue. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: kernel errors with HMM enabled

2019-03-14 Thread Michel Dänzer
of our amd-staging-drm-next includes this patch (about 126 down > from the tip). amd-staging-drm-next might be missing more HMM fixes from 5.1, probably better to wait until we've rebased on that before spending too much more effort on this. -- Earthling Michel Dänzer |

[PATCH xf86-video-ati] modesetting: add tile property support

2019-03-14 Thread Michel Dänzer
from amdgpu commit 6ee857726166f495abcd68e4ff60e3a09593d079) Signed-off-by: Michel Dänzer --- src/drmmode_display.c | 54 +-- src/drmmode_display.h | 3 +++ 2 files changed, 55 insertions(+), 2 deletions(-) diff --git a/src/drmmode_display.c b/src

[PATCH xf86-video-ati] Use radeon_finish in drmmode_crtc_scanout_update

2019-03-14 Thread Michel Dänzer
From: Michel Dänzer radeon_glamor_finish only works if we're using glamor, otherwise it'll crash. Fixes: ce7db51020d3 "Cancel pending scanout update in drmmode_crtc_scanout_update" Bug: https://bugs.debian.org/924540 Signed-off-by: Michel Dänzer --- src/drmmode_display.c | 2

Re: [PATCH] drm/amdgpu: revert "cleanup setting bulk_movable"

2019-03-13 Thread Michel Dänzer
ty(>evicted); > + > list_for_each_entry_safe(bo_base, tmp, >evicted, vm_status) { > struct amdgpu_bo *bo = bo_base->bo; > > Reviewed-by: Michel Dänzer Tested-by: Michel Dänzer -- Earthling Michel Dänzer |

Re: kernel BUG at drivers/gpu/drm//ttm/ttm_bo.c:196!

2019-03-12 Thread Michel Dänzer
On 2019-03-12 3:26 p.m., Koenig, Christian wrote: > Am 12.03.19 um 14:47 schrieb Michel Dänzer: >> On 2019-02-05 6:40 p.m., Michel Dänzer wrote: >>> FWIW, I've hit this twice now today, whereas I don't remember ever >>> hitting it before (not 100% sure though). >&

Re: kernel BUG at drivers/gpu/drm//ttm/ttm_bo.c:196!

2019-03-12 Thread Michel Dänzer
On 2019-02-05 6:40 p.m., Michel Dänzer wrote: > > FWIW, I've hit this twice now today, whereas I don't remember ever > hitting it before (not 100% sure though). > > I reverted the remaining hunk of the "cleanup setting bulk_movable" > change, and it survived a pi

Re: will xf86-video-amdgpu is capable to drive AMD readeon Pro wx2100

2019-03-12 Thread Michel Dänzer
86-video-amdgpu requires the amdgpu kernel driver. Assuming the latter is working with your card, the former will work (as well as the generic modesetting Xorg driver). -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast

Re: [patch] ras fix patch set

2019-03-11 Thread Michel Dänzer
ur editor is properly configured for the Linux kernel coding style. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing lis

Re: [PATCH] drm/amdgpu: limit the number of IVs processed at once

2019-03-08 Thread Michel Dänzer
mber of IVs processed at once */ > +#define AMDGPU_IH_MAX_NUM_IVS32 > + > struct amdgpu_device; > struct amdgpu_iv_entry; > > Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast |

[PATCH xf86-video-ati] Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows"

2019-03-08 Thread Michel Dänzer
From: Michel Dänzer This reverts commit 274703087f80342f51fa69c935bb9a1cb0c4ae47. Reports of visual corruption were bisected to this, e.g. https://bugs.archlinux.org/task/61941 . I can reproduce this with Turks, but not with Bonaire. I assume it's a Mesa/glamor bug, but let's revert for now

locking related bug detected since "drm/amdgpu: lookup vbios table to check ecc capability"

2019-03-08 Thread Michel Dänzer
in the commit log, and it doesn't seem related to checking a VBIOS table for ECC capability. Was it intended? P.S. AFAICT this patch wasn't submitted to the amd-gfx list for review. All changes must be reviewed here before being applied to amd-staging-drm-next. -- Earthling Michel Dänzer

Re: randr: Virtual monitor not present with MST display

2019-03-08 Thread Michel Dänzer
On 2019-03-06 5:35 p.m., Paul Menzel wrote: > On 03/06/19 15:55, Michel Dänzer wrote: >> On 2019-03-06 1:41 p.m., Paul Menzel wrote: >>> On 03/05/19 20:07, Alex Deucher wrote: >>>> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: >>> >>>&

Re: [PATCH] drm/amdgpu: enable bo priority setting from user space

2019-03-07 Thread Michel Dänzer
On 2019-03-07 11:48 a.m., zhoucm1 wrote: > On 2019年03月07日 17:55, Michel Dänzer wrote: >> On 2019-03-07 10:15 a.m., Chunming Zhou wrote: >>> Signed-off-by: Chunming Zhou >> Please provide corresponding UMD patches showing how this is to be used. > spec is here: > ht

Re: [PATCH] drm/amdgpu: enable bo priority setting from user space

2019-03-07 Thread Michel Dänzer
= >mman.bdev; > amdgpu_bo_placement_from_domain(bo, bp->domain); > + bo->tbo.priority = bp->priority; > if (bp->type == ttm_bo_type_kernel) > - bo->tbo.priority = 1; > + bo->tbo.priority = TTM_BO_PRIORITY_VERYHIGH; if (b

Re: [PATCH] remove amdgpu_vrr_atom

2019-03-07 Thread Michel Dänzer
ybe you ran into the Mesa bug fixed by https://gitlab.freedesktop.org/mesa/mesa/commit/c0a540f32067cc8cb126d9aa1eb12a11cf15373a?merge_request_iid=202 , or a similar bug elsewhere? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusi

[ANNOUNCE] xf86-video-ati 19.0.0

2019-03-06 Thread Michel Dänzer
e flipping in multi-X-Screen/Zaphod mode Michel Dänzer (30): dri3: Handle radeon_get_pixmap_bo returning NULL Handle pending scanout update in drmmode_crtc_scanout_free Make wait_pending_flip / handle_deferred symmetric in set_mode_major Allow up to six instances in Zaphod mode

Re: [PATCH 3/3] drm/amdgpu: more descriptive message if HMM not enabled v3

2019-03-06 Thread Michel Dänzer
t; > + "add CONFIG_ZONE_DEVICE=y in config file to fix this\n"); With the second line indentation fixed to properly line up with the opening parenthesis, Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | https://www.amd.com Libre software en

Re: [PATCH 3/3] drm/amdgpu: more descriptive message if HMM not enabled v2

2019-03-06 Thread Michel Dänzer
ed\n"); >>> +    DRM_WARN_ONCE("add CONFIG_ZONE_DEVICE=y in config file to fix >>> this\n"); >> >> One message please, apart from that looks good to me. >> >> Christian. >> > Do you mean use multiple line string with one DRM_

Re: randr: Virtual monitor not present with MST display

2019-03-06 Thread Michel Dänzer
ADs count is: -2, don't need to read it > > I didn’t provide the output of xrandr in my previous message. > > $ xrandr --listmonitors > Monitors: 2 > 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 > 1: +Di

Re: [PATCH 3/3] drm/amdgpu: more descriptive message if HMM not enabled

2019-03-06 Thread Michel Dänzer
On 2019-03-06 3:42 p.m., Yang, Philip wrote: > On 2019-03-06 4:05 a.m., Michel Dänzer wrote: >> On 2019-03-05 7:09 p.m., Yang, Philip wrote: >>> If using old kernel config file, CONFIG_ZONE_DEVICE is not selected, >>> so CONFIG_HMM and CONFIG_HMM_MIRROR is not enabled, t

[ANNOUNCE] xf86-video-amdgpu 19.0.0

2019-03-06 Thread Michel Dänzer
Plus other improvements and fixes. Thanks to everybody who contributed to this release in any way! Mario Kleiner (1): Fix crash when page flipping in multi-X-Screen/Zaphod mode Michel Dänzer (53): Post-release version bump Convert README to markdown Handle pending scan

Re: [PATCH 3/3] drm/amdgpu: more descriptive message if HMM not enabled

2019-03-06 Thread Michel Dänzer
so buggy/malicious userspace could spam dmesg with these errors. I'm afraid a different solution is needed. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdkfd: Fix "-Wmisleading-indentation" warning

2019-03-06 Thread Michel Dänzer
Leo, but I already sent a fix for this: https://patchwork.freedesktop.org/patch/290410/ -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx

Re: [PATCH] drm/amd/display: Don't ASSERT when total_planes == AMDGPU_MAX_PLANES

2019-03-05 Thread Michel Dänzer
On 2019-03-05 6:24 p.m., Nicholas Kazlauskas wrote: > [Why] > Can happen on ASICs with 6 planes, but this isn't a bug since we haven't > written outside the array. > > [How] > Use <= instead of <. > > Cc: Leo Li > Cc: Michel Dänzer > Reported-by: Mich

Re: [PATCH 06/18] drm/amd/display: Drop underlay plane support

2019-03-05 Thread Michel Dänzer
ere is one primary plane per CRTC */ > + primary_planes = dm->dc->caps.max_streams; > + ASSERT(primary_planes < AMDGPU_MAX_PLANES); This assertion fails for me with Bonaire. In fact, since AMDGPU_MAX_PLANES is 6, and primary_planes seems to be the number of CRTCs, it'll fail with

[PATCH] drm/amdkfd: Add curly braces around idr_for_each_entry_continue loop

2019-03-05 Thread Michel Dänzer
From: Michel Dänzer The compiler pointed out that one if block unintentionally wasn't part of the loop: In file included from ./include/linux/kernfs.h:14, from ./include/linux/sysfs.h:16, from ./include/linux/kobject.h:20, from ./include/linux

[PATCH xf86-video-ati 1/2] present: Check that flip and screen pixmap pitches match

2019-03-01 Thread Michel Dänzer
From: Michel Dänzer If they don't, flipping will result in corrupted display. Test case: * Run Xorg at 1920x1080 with no window manager * glxgears -geometry 2048x1080 The Present extension code in xserver 1.21 will check for this. (Ported from amdgpu commit

[PATCH xf86-video-ati 2/2] dri2: Call drm_queue_handle_deferred in dri2_deferred_event

2019-03-01 Thread Michel Dänzer
From: Michel Dänzer drm_queue_handler just puts the event on the signalled list; without calling drm_queue_handle_deferred, actual processing of the event may be delayed indefinitely, e.g. until another event arrives from the kernel. This could result in DRI2 clients hanging during DPMS off

Re: [PATCH xf86-video-amdgpu] Allow changing DCC parameters between flips

2019-03-01 Thread Michel Dänzer
Thanks Marek for the patch, but xf86-video-amdgpu patches are being reviewed as GitLab merge requests since the last release[0]. I'll create a merge request with this patch and some follow-up changes. [0] Isn't README.md clear enough on this? -- Earthling Michel Dänzer

Re: [PATCH xf86-video-amdgpu] Fix hang when entering into dpms-off mode

2019-03-01 Thread Michel Dänzer
On 2019-03-01 7:37 a.m., Liu, Aaron wrote: > @Michel Dänzer, > > I have reviewed your patch and verified it passed. Thanks Aaron, so I assume I can add Reviewed-by: Aaron Liu Tested-by: Aaron Liu ? > I couldn't merge this merge request to your master manually. Don't worry

Re: [PATCH xf86-video-amdgpu] Fix hang when entering into dpms-off mode

2019-02-28 Thread Michel Dänzer
On 2019-02-28 1:05 p.m., Michel Dänzer wrote: > On 2019-02-28 3:52 a.m., Aaron Liu wrote: >> >> @@ -900,7 +900,12 @@ CARD32 amdgpu_dri2_deferred_event(OsTimerPtr timer, >> CARD32 now, pointer data) >> delta_seq = delta_t * drmmode_crtc->dpms_last_fps

Re: [PATCH xf86-video-amdgpu] Fix hang when entering into dpms-off mode

2019-02-28 Thread Michel Dänzer
drm_now % 100, > This isn't a good solution I'm afraid, as it'll leave the struct amdgpu_drm_queue_entry memory associated with event_info->drm_queue_seq linked into the amdgpu_drm_queue list, which would gradually slow down processing of that list. I think I

Compiler warnings from RAS code

2019-02-28 Thread Michel Dänzer
^~ ./include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’ #define min(x, y) __careful_cmp(x, y, <) ^ drivers/gpu/drm//amd/amdgpu/amdgpu_ras.c:162:14: note: in expansion of macro ‘min’ ssize_t s = min(64ULL, size);

Re: KASAN caught amdgpu / HMM use-after-free

2019-02-28 Thread Michel Dänzer
-- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: KASAN caught amdgpu / HMM use-after-free

2019-02-27 Thread Michel Dänzer
to workaround the issue. Please push it to amd-staging-drm-next, so that others don't run into the issue as well. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___

KASAN caught amdgpu / HMM use-after-free

2019-02-27 Thread Michel Dänzer
See the attached dmesg excerpt. I've hit this a few times running piglit with amd-staging-drm-next, first on February 22nd. The memory was freed after calling hmm_mirror_unregister in amdgpu_mn_destroy. -- Earthling Michel Dänzer | https://www.amd.com Libre software

Re: [PATCH] drm/amdgpu: remove some old unused dpm helpers

2019-02-15 Thread Michel Dänzer
On 2019-02-14 9:58 p.m., Alex Deucher via amd-gfx wrote: > Carried over from radeon, but no longer used. > > Signed-off-by: Alex Deucher Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software e

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

2019-02-14 Thread Michel Dänzer
On 2019-02-14 5:57 p.m., Kazlauskas, Nicholas wrote: > On 2/14/19 11:47 AM, Grodzovsky, Andrey wrote: >> >> On 2/14/19 11:07 AM, Michel Dänzer wrote: >>> On 2019-02-14 4:54 p.m., Kazlauskas, Nicholas wrote: >>>> On 2/14/19 10:42 AM, Grodzovsky, Andrey wrote:

Re: [PATCH] drm/amd/display: Fix deadlock with display during hanged ring recovery.

2019-02-14 Thread Michel Dänzer
it at all. >> >> That a good point, I honestly can't remember any more why it's here... >> It does look unnecessary given that we are not validating the BO here. > > I think we reserve it to grab the tiling flags to update the plane > address (and some other bits of the

Re: "ring gfx timeout" with Vega 64 on mesa 19.0.0-rc2 and kernel 5.0.0-rc6 (GPU reset still not works)

2019-02-14 Thread Michel Dänzer
operation. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman

Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC.

2019-02-13 Thread Michel Dänzer
On 2019-02-13 10:53 a.m., Daniel Vetter wrote: > On Mon, Feb 11, 2019 at 04:01:12PM +0100, Michel Dänzer wrote: >> On 2019-02-09 7:52 a.m., Mario Kleiner wrote: >>> In VRR mode, keep track of the vblank count of the last >>> completed pageflip in amdgpu_crtc->las

Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC.

2019-02-12 Thread Michel Dänzer
On 2019-02-12 9:39 a.m., Mario Kleiner via dri-devel wrote: > On Mon, Feb 11, 2019 at 4:01 PM Michel Dänzer wrote: >> >> On 2019-02-09 7:52 a.m., Mario Kleiner wrote: >>> In VRR mode, keep track of the vblank count of the last >>> completed pageflip

Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC.

2019-02-11 Thread Michel Dänzer
gt; Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR > properties") > Signed-off-by: Mario Kleiner > Cc: > Cc: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Alex Deucher > Cc: Michel Dänzer I wonder if this couldn't be solved in a simpler

Re: BUG - unable to handle null pointer, bisected - drm/amd/display: add gpio lock/unlock

2019-02-07 Thread Michel Dänzer
On 2019-02-07 4:37 p.m., Alex Deucher wrote: > On Thu, Feb 7, 2019 at 10:33 AM Michel Dänzer wrote: >> >> On 2019-02-06 10:48 a.m., Przemek Socha wrote: >>> Good morning, >>> >>> on my Lenovo G50-45 a6310 APU with R4 Mullins commit >>> e261568

Re: BUG - unable to handle null pointer, bisected - drm/amd/display: add gpio lock/unlock

2019-02-07 Thread Michel Dänzer
nd machine without it is > working fine. Same for me with Tonga. Chiawen / Tony / other DC developers, any ideas? If it cannot be fixed quickly, let's revert this change for now. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast |

Re: kernel BUG at drivers/gpu/drm//ttm/ttm_bo.c:196!

2019-02-07 Thread Michel Dänzer
On 2019-02-07 10:58 a.m., Christian König wrote: > Am 05.02.19 um 18:40 schrieb Michel Dänzer: >> On 2019-02-05 4:45 p.m., Christian König wrote: >>> Possible, but unlikely. >>> >>> That sounds more like a reference counting problem where something is

Re: kernel BUG at drivers/gpu/drm//ttm/ttm_bo.c:196!

2019-02-05 Thread Michel Dänzer
ot 100% sure though). I reverted the remaining hunk of the "cleanup setting bulk_movable" change, and it survived a piglit run. Could just be luck, though... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast |

kernel BUG at drivers/gpu/drm//ttm/ttm_bo.c:196!

2019-02-05 Thread Michel Dänzer
Hit this with an amdgpu piglit run today, see the attached dmesg excerpt. It's ttm_bo_ref_bug() being called from ttm_bo_del_from_lru(). Maybe this is still fallout from the "cleanup setting bulk_movable" change? -- Earthling Michel Dänzer | http://www.amd

Re: [PATCH] Revert "Revert "drm/amd/powerplay: support Vega10 SOCclk and DCEFclk dpm level settings""

2019-02-04 Thread Michel Dänzer
> > Signed-off-by: Kenneth Feng Revert "Revert "..."" is kind of an ugly shortlog. :) It's nicer to re-use the original commit's log, possibly amended with an explanation why the change is applied again. -- Earthling Michel Dänzer | htt

Re: After upgrade mesa to 19.0.0~rc1 all vulkan based application stop working ["vulkan-cube" received SIGSEGV in radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pipeline.c:699]

2019-02-04 Thread Michel Dänzer
ched via steam play DXVK > - vulcan-cube (backtrace is included to this message) > > Last working mesa version: > 18.3.2-1 Please report RADV issues at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa=Drivers/Vulkan/radeon . -- Earthling Michel Dänzer |

Re: Bug#921004: downgrade to firmware-amd-graphics_20180825-1_all.deb

2019-01-31 Thread Michel Dänzer
e updates have been upstream > in linux-firmware for over a month now. It entered Debian sid about two weeks ago, so might have only entered Debian testing this week. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast |

Fwd: Bug#921004: downgrade to firmware-amd-graphics_20180825-1_all.deb

2019-01-31 Thread Michel Dänzer
Bad news I'm afraid, looks like the latest firmware (based on linux-firmware commit bc656509a3cfb60fcdfc905d7e23c18873e4e7b9 from 2019-01-14) broke some RX 580 cards. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast

[PATCH xf86-video-ati 1/7] dri3: Flush if necessary in dri3_fd_from_pixmap

2019-01-28 Thread Michel Dänzer
From: Michel Dänzer To make sure the client can't use the shared pixmap storage for direct rendering first, which could produce garbage. Bugzilla: https://bugs.freedesktop.org/109235 (Ported from amdgpu commit d168532ee739f7e33a2798051e64ba445dd3859f) Signed-off-by: Michel Dänzer --- src

[PATCH xf86-video-ati 5/7] Only update drmmode_crtc->flip_pending after actually submitting a flip

2019-01-28 Thread Michel Dänzer
From: Michel Dänzer And only clear it if it matches the framebuffer of the completed flip being processed. Fixes (WW) RADEON(0): flip queue failed: Device or resource busy (WW) RADEON(0): Page flip failed: Device or resource busy (EE) RADEON(0): present flip failed due to clobbering

[PATCH xf86-video-ati 6/7] Call drmHandleEvent again if it was interrupted by a signal

2019-01-28 Thread Michel Dänzer
From: Michel Dänzer drmHandleEvent can be interrupted by a signal in read(), in which case it doesn't process any events but returns -1, which drm_handle_event propagated to its callers. This could cause the following failure cascade: 1. drm_wait_pending_flip stopped waiting for a pending flip

[PATCH xf86-video-ati 7/7] Keep waiting for a pending flip if drm_handle_event returns 0

2019-01-28 Thread Michel Dänzer
From: Michel Dänzer drm_wait_pending_flip stopped waiting if drm_handle_event returned 0, but that might have processed only some unrelated DRM events. As long as the flip is pending, we have to keep waiting for its completion event. Noticed while working on the previous fix. (Ported from

[PATCH xf86-video-ati 4/7] Don't allow TearFree scanout flips to complete in the same vblank period

2019-01-28 Thread Michel Dänzer
From: Michel Dänzer We were using a relative target of 0, meaning "complete the flip ASAP". This could result in the flip sometimes, but not always completing in the same vertical blank period where the corresponding drawing occurred, potentially causing judder artifacts with ap

[PATCH xf86-video-ati 2/7] dri2: Flush in dri2_create_buffer2 after calling glamor_set_pixmap_bo

2019-01-28 Thread Michel Dänzer
From: Michel Dänzer To make sure the client can't use the shared pixmap storage for direct rendering first, which could produce garbage. Bugzilla: https://bugs.freedesktop.org/109235 (Ported from amdgpu commit ebd32b1c07208f8dbe853e089f5e4b7c6a7a658a) Signed-off-by: Michel Dänzer --- src

[PATCH xf86-video-ati 3/7] glamor: Avoid glamor_create_pixmap for pixmaps backing windows

2019-01-28 Thread Michel Dänzer
From: Michel Dänzer If the compositing manager uses direct rendering (as is usually the case these days), the storage of a pixmap allocated by glamor_create_pixmap needs to be reallocated for sharing it with the compositing manager. Instead, allocate pixmap storage which can be shared directly

Re: [PATCH] drm/amd/display - Don't leak memory when updating streams

2019-01-28 Thread Michel Dänzer
ut we wouldn't should be doing anything in that case anyway. > > Fixes: c00e0cc0fdc0 ("drm/amd/display: Call into DC once per multiplane flip") > Fixes: ea39594e0855 ("drm/amd/display: Perform plane updates only when > needed") > > Cc: Michel Dänzer &g

Re: [PATCH 05/20] drm/amd/display: Call into DC once per multiplane flip

2019-01-28 Thread Michel Dänzer
), GFP_KERNEL); > + > + if (!flip) > + dm_error("Failed to allocate update bundles\n"); I can't see where this memory is freed, maybe this is the leak? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast |

xf86-video-amdgpu merge request !24 is ready for review

2019-01-25 Thread Michel Dänzer
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/24 Thanks in advance for taking a look! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

2019-01-24 Thread Michel Dänzer
cache coherent likely not working *at >>> all* unless the optimization is enabled. >> >> As Michel tried to explain this CAN'T happen. The optimization is a >> purely optional request from userspace. >> > > Right. > > So in that case,

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

2019-01-24 Thread Michel Dänzer
t; - if (bo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) >> - DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT >> for " >> - "better performance thanks to >> write-combining\n"); FWIW, pleas

Re: [PATCH 04/20] drm/amd/display: Know what a pageflip is

2019-01-23 Thread Michel Dänzer
; afb->address != old_afb->address); The second check after the || cannot be true if old_plane_state->fb == new_plane_state->fb, so it's dead code. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa a

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

2019-01-21 Thread Michel Dänzer
On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote: > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote: >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote: >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote: >>>> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote: >

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

2019-01-21 Thread Michel Dänzer
On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote: > On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote: >> >> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote: >>> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote: >>>> >>>> On 2019-01-21 5:30 p.m., Ard B

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

2019-01-21 Thread Michel Dänzer
On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote: > On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote: >> >> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote: >>> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote: >>> >>>> Until that happens we sh

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

2019-01-21 Thread Michel Dänzer
; 'optimization' to get things working. FWIW, the amdgpu driver doesn't rely on non-snooped transfers for correct basic operation (the scenario Christian brought up is a very specialized use-case), so that shouldn't be an issue. -- Earthling Michel Dänzer |

Re: [PATCH libdrm] amdgpu: update amdgpu_drm.h

2019-01-16 Thread Michel Dänzer
m, see the rules for updating this. >> >> IIRC the code must land in an upstream kernel before it can be committed >> to libdrm. >> >> Christian. >> > > It looks like it's all in the master branch. That's good, but please follow the pr

xf86-video-amdgpu merge request !21 is ready for review

2019-01-16 Thread Michel Dänzer
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21 Thanks in advance for taking a look! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer

Re: pitch alignment questions

2019-01-14 Thread Michel Dänzer
On 2019-01-11 10:37 p.m., Yu Zhao wrote: > On Fri, Jan 11, 2019 at 04:27:44PM +0100, Michel Dänzer wrote: >> On 2019-01-10 6:56 p.m., Przemek Socha wrote: >>> >>> [ 147.846148] [drm:amdgpu_display_user_framebuffer_create [amdgpu]] >>> Invalid >

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

2019-01-14 Thread Michel Dänzer
is_swiotlb_buffer, > maybe that gives a clue why we are hitting the swiotlb code here. Any progress? https://bugzilla.kernel.org/show_bug.cgi?id=202261 was also filed about this. I hope everyone's clear that this needs to be resolved one way or another by 5.0 final (though

Re: [PATCH] drm/ttm: stop always moving BOs on the LRU on page fault

2019-01-14 Thread Michel Dänzer
On 2019-01-11 8:12 p.m., Christian König wrote: > Am 11.01.19 um 15:17 schrieb Michel Dänzer: >> On 2019-01-11 2:15 p.m., Christian König wrote: >>> Move the BO on the LRU only when it is actually moved by a DMA >>> operation. >>> >>> [...] &

  1   2   3   4   5   6   7   8   9   10   >