Re: [PATCH] drm/amd/display: Use pixel encoding 444 for dongle usb-c to hdmi

Hi Harry, As suggested I created the issue here https://gitlab.freedesktop.org/drm/amd/issues/2 with a picture of the problem attached. Please take a look, thx! Julien On Mon, Nov 11, 2019 at 1:11 PM Harry Wentland wrote: > On 2019-10-08 2:15 p.m., Julien Isorce wrote: > >

Re: [PATCH] drm/amd/display: Use pixel encoding 444 for dongle usb-c to hdmi

Hi, gentle ping ? Thx in advance. On Tue, Oct 8, 2019 at 11:15 AM Julien Isorce wrote: > Hi Harry, > > I can reproduce on LG, Samsung and NEC monitors. > > "Have you checked whether the driver picks RGB or YCBCR420 without your > patch?" -> it was selecting

Re: [PATCH] drm/amd/display: Use pixel encoding 444 for dongle usb-c to hdmi

Hi, Gentle ping ? Thx Julien On Fri, Oct 11, 2019 at 12:31 PM Julien Isorce wrote: > Hi Harry, > > Do you need more information ? > > Thx > Julien > > On Tue, Oct 8, 2019 at 11:15 AM Julien Isorce > wrote: > >> Hi Harry, >> >> I can reproduce

Re: [PATCH] drm/amd/display: Use pixel encoding 444 for dongle usb-c to hdmi

Hi Harry, Do you need more information ? Thx Julien On Tue, Oct 8, 2019 at 11:15 AM Julien Isorce wrote: > Hi Harry, > > I can reproduce on LG, Samsung and NEC monitors. > > "Have you checked whether the driver picks RGB or YCBCR420 without your > patch?&q

Re: [PATCH] drm/amd/display: Use pixel encoding 444 for dongle usb-c to hdmi

nderstand how the pinkish color issue looks. Do you see > a pinkish color at the transition from grey to another color? Or is the > entire grey area pinkish? > > Thanks, > Harry > > On 2019-10-08 12:06 p.m., Julien Isorce wrote: > > Hi, > > > > Gen

Re: [PATCH] drm/amd/display: Use pixel encoding 444 for dongle usb-c to hdmi

Hi, Gentle ping ? Thx Julien On Tue, Oct 1, 2019 at 3:21 PM Julien Isorce wrote: > Fix pinkish color issue around grey areas. This also happens > when not using any dongle so directly with a usb-c to Display > Port cable. Meaning there is something wrong when using pixel >

[PATCH] drm/amd/display: Use pixel encoding 444 for dongle usb-c to hdmi

HDMI without dongle. This way users will see the same thing on 2 identical screens when one is connected with hdmi-to-hdmi and the other is connected with usb-c-to-hdmi. Signed-off-by: Julien Isorce --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 + 1 file changed, 5 insertions

Re: [PATCH 0/7] *** GPU recover V3 ***

Hi Monk, It was more a general question. So you never need to do an electrical reboot when a gpu reset fails ? Thx Julien On 10 November 2017 at 07:51, Liu, Monk <monk@amd.com> wrote: > Please share the dmesg log, and what’s the chip are you using ? > > > >

Re: [PATCH 0/7] *** GPU recover V3 ***

euc...@gmail.com> wrote: > On Thu, Nov 9, 2017 at 4:35 AM, Julien Isorce <julien.iso...@gmail.com> > wrote: > > Hi Monk. > > > > I am interested on this. Currently when a "ring X stalled for more than N > > sec" happens it usually goes into the

Re: [PATCH 0/7] *** GPU recover V3 ***

Hi Monk. I am interested on this. Currently when a "ring X stalled for more than N sec" happens it usually goes into the gpu reset routine. Does it always cause the vram to be lost ? Could you explain what happens if the vram remains lost ? I am asking this because I experienced some recurrent

[PATCH v2] drm/radeon: only warn once in radeon_ttm_bo_destroy if va list not empty

Encountered a dozen of exact same backtraces when mesa's pb_cache_release_all_buffers is called after that a gpu reset failed. v2: Remove superfluous error message added in v1. bug: https://bugs.freedesktop.org/show_bug.cgi?id=96271 Signed-off-by: Julien Isorce <jiso...@oblong.com> --- d

[PATCH] drm/radeon: only warn once in radeon_ttm_bo_destroy if va list not empty

_close. But it will only work if the vm_manager succeeded to be re-enabled after a gpu reset. bug: https://bugs.freedesktop.org/show_bug.cgi?id=96271 Signed-off-by: Julien Isorce <jiso...@oblong.com> --- drivers/gpu/drm/radeon/radeon_object.c | 8 +++- 1 file changed, 7 insertions(+)

[PATCH] drm/radeon: reject bo creation from ioctl when the gpu is disabled

led after a gpu reset while the GFX ring was not responding so accel was disabled. https://bugs.freedesktop.org/show_bug.cgi?id=96271 Signed-off-by: Julien Isorce <jiso...@oblong.com> --- drivers/gpu/drm/radeon/radeon_gem.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/d

Re: [PATCH] [RFC] drm/radeon: clear WC flag when moving bo from vram to gtt

On 24 April 2017 at 10:51, Christian König <deathsim...@vodafone.de> wrote: > Am 24.04.2017 um 11:42 schrieb Julien Isorce: > >> But re-add the flag is the bo is moved back to vram. >> >> This fixes "ring 0/3 stalled" issue which happens when the driver

[PATCH] [RFC] drm/radeon: clear WC flag when moving bo from vram to gtt

But re-add the flag is the bo is moved back to vram. This fixes "ring 0/3 stalled" issue which happens when the driver evicts bo from vram to gtt, at least on TAHITI and CAPVERDE. I do not know the exact reason among the following: - si_copy_dma from vram to gtt is slow if WC (only for

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

17 um 10:59 schrieb Michel Dänzer: >>> >>>> On 28/03/17 08:00 PM, Julien Isorce wrote: >>>> >>>>> On 28 March 2017 at 10:36, Michel Dänzer <mic...@daenzer.net >>>>> <mailto:mic...@daenzer.net>> wrote: >>>>> >>>&

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

On 28 March 2017 at 10:36, Michel Dänzer <mic...@daenzer.net> wrote: > On 28/03/17 05:24 PM, Julien Isorce wrote: > > Hi Michel, > > > > About the hard lockup, I noticed that I cannot have it with the > > following conditions: > > > > 1. soft lockup fi

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

erde 2048M ) I am happy to try any other suggestion. Thx Julien On 24 March 2017 at 19:01, Julien Isorce <julien.iso...@gmail.com> wrote: > Hi Michel, > > No this change does not help on the other issue (hard lockup). > I have no tried it in combination with the 0 -> i c

Re: [PATCH] drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags

> results in an infinite loop. >> >> Fixes: 2a85aedd117c ("drm/radeon: Try evicting from CPU accessible to >> inaccessible VRAM first") >> Reported-by: Zachary Michaels <zmicha...@oblong.com> >> Reported-and-Tested-by: Julie

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, No this change does not help on the other issue (hard lockup). I have no tried it in combination with the 0 -> i change. Thx anyway. Julien On 24 March 2017 at 10:03, Michel Dänzer wrote: > On 24/03/17 12:31 AM, Zachary Michaels wrote: > > > > I should also

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, I double checked and you are right, the change 0 -> i works. Cheers Julien On 24 March 2017 at 09:59, Michel Dänzer <mic...@daenzer.net> wrote: > On 24/03/17 06:50 PM, Julien Isorce wrote: > > Hi Michel, > > > > (Just for other readers my reply has bee

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

this other issue has some similarities (same ioctl call). But in general, isn't "radeon_lockup_timeout" supposed to detect this situation ? Thx Julien On 24 March 2017 at 09:24, Michel Dänzer <mic...@daenzer.net> wrote: > On 23/03/17 06:26 PM, Julien Isorce wrote: > >

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, When it happens, the main thread of our gl based app is stuck on a ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but same thing happens if true. Other threads are only si_shader:0,1,2,3 and are doing nothing, just waiting for jobs. I can also do sudo gdb -p $(pidof