[Nouveau] [PATCH 2/2] present: don't enable if there's no acceleration
All the present logic relies on EXA being used to wrap everything. Unclear if present could even be used without the other things EXA enables, but better be safe. Signed-off-by: Ilia Mirkin --- src/nv_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/nv_driver.c b/src/nv_driver.c index a63674c..e72a6b6 100644 --- a/src/nv_driver.c +++ b/src/nv_driver.c @@ -1489,7 +1489,7 @@ NVScreenInit(SCREEN_INIT_ARGS_DECL) xf86SetBlackWhitePixels(pScreen); - if (nouveau_present_init(pScreen)) + if (pNv->AccelMethod == EXA && nouveau_present_init(pScreen)) xf86DrvMsg(pScrn->scrnIndex, X_INFO, "Hardware support for Present enabled\n"); else -- 2.26.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/2] drmmode: fix screen resize without acceleration
This got broken with commit 86024cee back in 2014! drmmode_pixmap/nouveau_pixmap expect there to be EXA wrapping around the pixmap now, which is not there without accel. Signed-off-by: Ilia Mirkin --- src/drmmode_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index 89927a4..69421e1 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -1561,7 +1561,7 @@ drmmode_xf86crtc_resize(ScrnInfoPtr scrn, int width, int height) } ppix = screen->GetScreenPixmap(screen); - if (pNv->AccelMethod >= NONE) + if (pNv->AccelMethod > NONE) nouveau_bo_ref(pNv->scanout, &drmmode_pixmap(ppix)->bo); screen->ModifyPixmapHeader(ppix, width, height, -1, -1, pitch, (pNv->AccelMethod > NONE || pNv->ShadowPtr) ? -- 2.26.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)
Intel (i915) uses the same fbdev emulation layer, so should be largely identical. Just make sure you're using a v4.12+ kernel -- I believe you mentioned that your Intel system was using 4.9, so that's expected to not support overallocation. You might be interested instead in making a kms client which does all this, as fbdev is deprecated and is unlikely to see any further development (even to extend the emulation layer to provide features various dedicated drivers may have had). Some samples available in e.g. kmscube: https://cgit.freedesktop.org/mesa/kmscube/ (it used to be much simpler, but has grown various demo features over the years). Good luck! -ilia On Sun, Jul 5, 2020 at 7:51 PM Michael T. Kloos wrote: > Oops, the FBIOPAN_DISPLAY ioctl error was a stupid mistake on mistake on > my part. Thanks for the info on where the validation code was. Comparing > against that made it easy to find the mistake. It's working now, > well...where I have been able to get over-allocation working! Thanks for > the help. If I can't get the over-allocation to work on my other systems, > I'll take it up in Intel Graphics specific channels. While the code is a > mess right now, here is a link to the program: > https://github.com/EchelonX-Ray/ttygraphics . I'm just trying to learn > about this and you really helped. > On 7/5/20 7:17 PM, Ilia Mirkin wrote: > > Check fb_pan_display in drivers/video/fbdev/core/fbmem.c for the > argument validation of the FBIOPAN_DISPLAY ioctl. > > CONFIG_FB_NVIDIA is a dedicated fbdev driver, not compatible with > nouveau (it takes over the relevant PCI device). It also won't support > your Pascal GPU, I believe -- I think it MIGHT support the Tesla > generation (i.e. G80..GT21x) but definitely not anything newer. Most > likely it supports pre-G80 GPUs, and again, not compatible with > nouveau. > > DRM-based drivers use the DRM <-> FBDEV emulation layer to provide an > fbdev interface for legacy applications. The fbdev emulation acts as > sort of a regular DRM client and exposes the FBDEV API. > > The overallocation logic was added to this emulation layer in commit > 5f15257689bfa, which is included in v4.12 and later kernels. > > Hope this helps, > > -ilia > > On Sun, Jul 5, 2020 at 7:02 PM Michael T. Kloos > wrote: > > Well...it's been a bit of a mixed bag. Setting > drm_kms_helper.drm_fbdev_overalloc=200 set the vinfo.yres_virtual to > 2160 as opposed to 1080 (My monitor vertical resolution) This fixed the > mmap() problem. However, it only worked on my main workstation. My > laptop running Intel graphics wasn't affected by the change in kernel > cmdline. My workstation is a custom build from a few years ago with a > GTX 1060 6GB, running Gentoo(Kernel version: 5.4) machine, and my laptop > running Manjaro. I also can not get the IOCTL FBIOPAN_DISPLAY to work. > It is now giving me an invalid argument error. I have set vinfo.xoffset > and vinfo.yoffset to 0 earlier in my program to try to eliminate them as > variables. > > Other factors that may be at play: > > -I am trying to run this from an alternate TTY. I have a graphical > environment on TTY7 with x.org. I think it is using the DRM interface. > Maybe there is a conflict. > -Maybe I am missing a driver in my Gentoo kernel config? I'm still > learning about it, but going into my workstation's kernel config, I > noticed that CONFIG_FB_NVIDIA was set to "n". > > Do you know when CONFIG_DRM_FBDEV_OVERALLOC went into the kernel? I was > about to try this on my MacBook Pro running Gentoo, but I will have to > recompile upgrade the kernel before I can give a report (It is currently > running: 4.9). I couldn't find it in menuconfig so I doubt the cmdline > would make a difference. > > I really appreciate the help. I've been looking header files and a such > trying to cobble together some information to figure this out. I hate > to bother you with this because it seems slightly off topic. > > On 7/5/20 3:45 PM, Ilia Mirkin wrote: > > Try booting with drm_kms_helper.drm_fbdev_overalloc=200 and see if it > works with that. (There's also CONFIG_DRM_FBDEV_OVERALLOC which sets > the default.) > > Cheers, > >-ilia > > On Sun, Jul 5, 2020 at 3:41 PM > wrote: > > I am not familiar with that setting, but I have really struggled to find > documentation on dealing with the framebuffer. Referring to this guide, > "http://betteros.org/tut/graphics1.php#doublebuffer"; > <http://betteros.org/tut/graphics1.php#doublebuffer>, I attempted to set the > mmap allocation size to double, but it caused the mmap to fail. I no longer > believe that it is a driver is
Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)
Check fb_pan_display in drivers/video/fbdev/core/fbmem.c for the argument validation of the FBIOPAN_DISPLAY ioctl. CONFIG_FB_NVIDIA is a dedicated fbdev driver, not compatible with nouveau (it takes over the relevant PCI device). It also won't support your Pascal GPU, I believe -- I think it MIGHT support the Tesla generation (i.e. G80..GT21x) but definitely not anything newer. Most likely it supports pre-G80 GPUs, and again, not compatible with nouveau. DRM-based drivers use the DRM <-> FBDEV emulation layer to provide an fbdev interface for legacy applications. The fbdev emulation acts as sort of a regular DRM client and exposes the FBDEV API. The overallocation logic was added to this emulation layer in commit 5f15257689bfa, which is included in v4.12 and later kernels. Hope this helps, -ilia On Sun, Jul 5, 2020 at 7:02 PM Michael T. Kloos wrote: > > Well...it's been a bit of a mixed bag. Setting > drm_kms_helper.drm_fbdev_overalloc=200 set the vinfo.yres_virtual to > 2160 as opposed to 1080 (My monitor vertical resolution) This fixed the > mmap() problem. However, it only worked on my main workstation. My > laptop running Intel graphics wasn't affected by the change in kernel > cmdline. My workstation is a custom build from a few years ago with a > GTX 1060 6GB, running Gentoo(Kernel version: 5.4) machine, and my laptop > running Manjaro. I also can not get the IOCTL FBIOPAN_DISPLAY to work. > It is now giving me an invalid argument error. I have set vinfo.xoffset > and vinfo.yoffset to 0 earlier in my program to try to eliminate them as > variables. > > Other factors that may be at play: > > -I am trying to run this from an alternate TTY. I have a graphical > environment on TTY7 with x.org. I think it is using the DRM interface. > Maybe there is a conflict. > -Maybe I am missing a driver in my Gentoo kernel config? I'm still > learning about it, but going into my workstation's kernel config, I > noticed that CONFIG_FB_NVIDIA was set to "n". > > Do you know when CONFIG_DRM_FBDEV_OVERALLOC went into the kernel? I was > about to try this on my MacBook Pro running Gentoo, but I will have to > recompile upgrade the kernel before I can give a report (It is currently > running: 4.9). I couldn't find it in menuconfig so I doubt the cmdline > would make a difference. > > I really appreciate the help. I've been looking header files and a such > trying to cobble together some information to figure this out. I hate > to bother you with this because it seems slightly off topic. > > On 7/5/20 3:45 PM, Ilia Mirkin wrote: > > Try booting with drm_kms_helper.drm_fbdev_overalloc=200 and see if it > > works with that. (There's also CONFIG_DRM_FBDEV_OVERALLOC which sets > > the default.) > > > > Cheers, > > > >-ilia > > > > On Sun, Jul 5, 2020 at 3:41 PM wrote: > >> I am not familiar with that setting, but I have really struggled to find > >> documentation on dealing with the framebuffer. Referring to this guide, > >> "http://betteros.org/tut/graphics1.php#doublebuffer";, I attempted to set > >> the mmap allocation size to double, but it caused the mmap to fail. I no > >> longer believe that it is a driver issue, though, because I just tried it > >> again on a dell laptop with Intel HD Graphics 4400 to the same failure. > >> > >> On Jul 5, 2020 12:35, Ilia Mirkin wrote: > >> > >> Are you setting the overallocation to 200? > >> > >> On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos > >> wrote: > >>> Does NOUVEAU support mmaping a double-sized Framebuffer? > >>> When attempting to run, where fd refers to "/dev/fb0": > >>> > >>> mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > >>> > >>> I get back an invalid argument error. This doesn't happen if I only > >>> request a single screensize. Is this a limitation of the driver? > >>> > >>> ___ > >>> Nouveau mailing list > >>> Nouveau@lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/nouveau > >> ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)
Try booting with drm_kms_helper.drm_fbdev_overalloc=200 and see if it works with that. (There's also CONFIG_DRM_FBDEV_OVERALLOC which sets the default.) Cheers, -ilia On Sun, Jul 5, 2020 at 3:41 PM wrote: > > I am not familiar with that setting, but I have really struggled to find > documentation on dealing with the framebuffer. Referring to this guide, > "http://betteros.org/tut/graphics1.php#doublebuffer";, I attempted to set the > mmap allocation size to double, but it caused the mmap to fail. I no longer > believe that it is a driver issue, though, because I just tried it again on a > dell laptop with Intel HD Graphics 4400 to the same failure. > > On Jul 5, 2020 12:35, Ilia Mirkin wrote: > > Are you setting the overallocation to 200? > > On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos > wrote: > > > > Does NOUVEAU support mmaping a double-sized Framebuffer? > > When attempting to run, where fd refers to "/dev/fb0": > > > > mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > > > I get back an invalid argument error. This doesn't happen if I only > > request a single screensize. Is this a limitation of the driver? > > > > ___ > > Nouveau mailing list > > Nouveau@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/nouveau > > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)
Are you setting the overallocation to 200? On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos wrote: > > Does NOUVEAU support mmaping a double-sized Framebuffer? > When attempting to run, where fd refers to "/dev/fb0": > > mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > I get back an invalid argument error. This doesn't happen if I only > request a single screensize. Is this a limitation of the driver? > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Remove debug info from nouveau driver
You probably have drm.debug set to something. On Tue, Jun 23, 2020 at 4:42 AM Mathieu Malaterre wrote: > > Hi there, > > I am gettings tons of messages in dmesg output such as: > > [...] > [ 2419.238990] [drm:drm_mode_addfb2 [drm]] [FB:65] > [ 2419.243388] 00a0 2 base507c_ntfy_set > [ 2419.243391] 0060 > [ 2419.243391] f000 > [ 2419.243393] 0084 1 base827c_image_set > [ 2419.243394] 0010 > [ 2419.243395] 00c0 1 base827c_image_set > [ 2419.243395] fb7a > [ 2419.243396] 0110 2 base827c_image_set > [ 2419.243397] > [ 2419.243398] > [ 2419.243399] 0800 5 base827c_image_set > [ 2419.243399] 0007ce00 > [ 2419.243400] > [ 2419.243400] 04380780 > [ 2419.243401] 7804 > [ 2419.243402] cf00 > [ 2419.243408] 0080 1 base507c_update > [ 2419.243409] > [...] > > Does anyone know how to remove those extra debug info from nouveau driver ? > > For reference: > > # cat /sys/module/nouveau/parameters/debug > (null) > > Thanks much > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau on G5 Macs
OK. That's not tearing. That's like a bad pitch on an image. (Presumably you only find the second image, IMG_1968.jpg, problematic?) I'm guessing you're using a GL-based compositor, which I fully expect to work poorly. Please try a non-compositing or XRender-based compositing environment. Cheers, -ilia On Mon, Jun 22, 2020 at 2:15 PM Jeroen Diederen wrote: > > This is with 64k page size. > > > > Ilia Mirkin schreef op 2020-06-22 19:27: > > I suspect screen tearing (as it's usually defined) is to be expected. > > Can you take a photo of what you're seeing, since I'm suspecting it's > > more than regular screen tearing? > > > > On Mon, Jun 22, 2020 at 12:08 PM Jeroen Diederen > > wrote: > >> > >> Hi Ilia, > >> > >> I experience screen tearing for both 64k and 4k page size. > >> My iMac G5 has an nVidia Geforce FX 5200 Ultra GPU. > >> > >> Regards, > >> Jeroen > >> > >> Ilia Mirkin schreef op 2020-06-22 17:25: > >> > Which GPU do you have? The NV40 AGP board (GeForce 6800) works > >> > particularly poorly. However as long as you go with 4k pages (and > >> > there's no real benefit to 64k pages for most applications), basic > >> > things should work. I wouldn't recommend using a GL-based compositor > >> > though. > >> > > >> > Which distortion are you talking about? > >> > > >> > Cheers, > >> > > >> > -ilia > >> > > >> > On Mon, Jun 22, 2020 at 11:10 AM Jeroen Diederen > >> > wrote: > >> >> > >> >> Hi all, > >> >> > >> >> I have been trying to solve nouveau issues on my iMac G5 for ages. As > >> >> far as I can understand it, there is a problem with nouveau and page > >> >> size mapping. I tried both 64K and 4K page size kernels and the the > >> >> result is always distorted video. > >> >> There is an old To-Do list, which says "fix the page size mapping > >> >> problem on G5/64 bit for exposing fifo regs" on > >> >> https://nouveau.freedesktop.org/wiki/ToDo/. > >> >> > >> >> Is there any chance that this bug will be fixed ? I am not a > >> >> programmer, > >> >> so I can't be of any help. > >> >> > >> >> Jeroen Diederen > >> >> ___ > >> >> Nouveau mailing list > >> >> Nouveau@lists.freedesktop.org > >> >> https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau on G5 Macs
I suspect screen tearing (as it's usually defined) is to be expected. Can you take a photo of what you're seeing, since I'm suspecting it's more than regular screen tearing? On Mon, Jun 22, 2020 at 12:08 PM Jeroen Diederen wrote: > > Hi Ilia, > > I experience screen tearing for both 64k and 4k page size. > My iMac G5 has an nVidia Geforce FX 5200 Ultra GPU. > > Regards, > Jeroen > > Ilia Mirkin schreef op 2020-06-22 17:25: > > Which GPU do you have? The NV40 AGP board (GeForce 6800) works > > particularly poorly. However as long as you go with 4k pages (and > > there's no real benefit to 64k pages for most applications), basic > > things should work. I wouldn't recommend using a GL-based compositor > > though. > > > > Which distortion are you talking about? > > > > Cheers, > > > > -ilia > > > > On Mon, Jun 22, 2020 at 11:10 AM Jeroen Diederen > > wrote: > >> > >> Hi all, > >> > >> I have been trying to solve nouveau issues on my iMac G5 for ages. As > >> far as I can understand it, there is a problem with nouveau and page > >> size mapping. I tried both 64K and 4K page size kernels and the the > >> result is always distorted video. > >> There is an old To-Do list, which says "fix the page size mapping > >> problem on G5/64 bit for exposing fifo regs" on > >> https://nouveau.freedesktop.org/wiki/ToDo/. > >> > >> Is there any chance that this bug will be fixed ? I am not a > >> programmer, > >> so I can't be of any help. > >> > >> Jeroen Diederen > >> ___ > >> Nouveau mailing list > >> Nouveau@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau on G5 Macs
Which GPU do you have? The NV40 AGP board (GeForce 6800) works particularly poorly. However as long as you go with 4k pages (and there's no real benefit to 64k pages for most applications), basic things should work. I wouldn't recommend using a GL-based compositor though. Which distortion are you talking about? Cheers, -ilia On Mon, Jun 22, 2020 at 11:10 AM Jeroen Diederen wrote: > > Hi all, > > I have been trying to solve nouveau issues on my iMac G5 for ages. As > far as I can understand it, there is a problem with nouveau and page > size mapping. I tried both 64K and 4K page size kernels and the the > result is always distorted video. > There is an old To-Do list, which says "fix the page size mapping > problem on G5/64 bit for exposing fifo regs" on > https://nouveau.freedesktop.org/wiki/ToDo/. > > Is there any chance that this bug will be fixed ? I am not a programmer, > so I can't be of any help. > > Jeroen Diederen > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 2dd4d163cd9c ("drm/nouveau: remove open-coded version of remove_conflicting_pci_framebuffers()")
Hi Boris, There was a fixup to that patch that you'll also have to revert first -- 7dbbdd37f2ae7dd4175ba3f86f4335c463b18403. I guess there's some subtle difference between the old open-coded logic and the helper, they were supposed to be identical. Cheers, -ilia On Thu, Jun 18, 2020 at 4:09 PM Borislav Petkov wrote: > > Hi, > > my test box won't boot 5.8-rc1 all the way but stops at > > ... > fb0: switching to nouveaufb from EFI VGA > <-- EOF > > I've bisected it to the commit in $Subject, see below. Unfortunately, it > doesn't revert cleanly so I can't really do the final test of reverting > it ontop of 5.8-rc1 to confirm that this one is really causing it. > > Any ideas? > > GPU is: > > [5.678614] fb0: switching to nouveaufb from EFI VGA > [5.685577] Console: switching to colour dummy device 80x25 > [5.691865] nouveau :03:00.0: NVIDIA GT218 (0a8c00b1) > [5.814409] nouveau :03:00.0: bios: version 70.18.83.00.08 > [5.823559] nouveau :03:00.0: fb: 512 MiB DDR3 > [6.096680] [TTM] Zone kernel: Available graphics memory: 8158364 KiB > [6.103327] [TTM] Zone dma32: Available graphics memory: 2097152 KiB > [6.109951] [TTM] Initializing pool allocator > [6.114405] [TTM] Initializing DMA pool allocator > [6.119256] nouveau :03:00.0: DRM: VRAM: 512 MiB > [6.124285] nouveau :03:00.0: DRM: GART: 1048576 MiB > [6.129677] nouveau :03:00.0: DRM: TMDS table version 2.0 > [6.135534] nouveau :03:00.0: DRM: DCB version 4.0 > [6.140755] nouveau :03:00.0: DRM: DCB outp 00: 02000360 > [6.147273] nouveau :03:00.0: DRM: DCB outp 01: 02000362 00020010 > [6.153782] nouveau :03:00.0: DRM: DCB outp 02: 028003a6 0f220010 > [6.160292] nouveau :03:00.0: DRM: DCB outp 03: 01011380 > [6.166810] nouveau :03:00.0: DRM: DCB outp 04: 08011382 00020010 > [6.173306] nouveau :03:00.0: DRM: DCB outp 05: 088113c6 0f220010 > [6.179829] nouveau :03:00.0: DRM: DCB conn 00: 00101064 > [6.185553] nouveau :03:00.0: DRM: DCB conn 01: 00202165 > [6.196145] nouveau :03:00.0: DRM: MM: using COPY for buffer copies > [6.233659] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [6.311939] nouveau :03:00.0: DRM: allocated 1920x1080 fb: 0x7, bo > (ptrval) > [6.320736] fbcon: nouveaudrmfb (fb0) is primary device > [6.392722] tsc: Refined TSC clocksource calibration: 3591.346 MHz > [6.392788] clocksource: tsc: mask: 0x max_cycles: > 0x33c46403b59, max_idle_ns: 440795293818 ns > [6.392930] clocksource: Switched to clocksource tsc > [6.509946] Console: switching to colour frame buffer device 240x67 > [6.546287] nouveau :03:00.0: fb0: nouveaudrmfb frame buffer device > [6.555021] [drm] Initialized nouveau 1.3.1 20120801 for :03:00.0 on > minor 0 > > Thx. > > git bisect start > # good: [3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162] Linux 5.7 > git bisect good 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 > # bad: [b3a9e3b9622ae10064826dccb4f7a52bd88c7407] Linux 5.8-rc1 > git bisect bad b3a9e3b9622ae10064826dccb4f7a52bd88c7407 > # bad: [ee01c4d72adffb7d424535adf630f2955748fa8b] Merge branch 'akpm' > (patches from Andrew) > git bisect bad ee01c4d72adffb7d424535adf630f2955748fa8b > # bad: [16d91548d1057691979de4686693f0ff92f46000] Merge tag 'xfs-5.8-merge-8' > of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux > git bisect bad 16d91548d1057691979de4686693f0ff92f46000 > # good: [cfa3b8068b09f25037146bfd5eed041b78878bee] Merge tag 'for-linus-hmm' > of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma > git bisect good cfa3b8068b09f25037146bfd5eed041b78878bee > # good: [3fd911b69b3117e03181262fc19ae6c3ef6962ce] Merge tag > 'drm-misc-next-2020-05-07' of git://anongit.freedesktop.org/drm/drm-misc into > drm-next > git bisect good 3fd911b69b3117e03181262fc19ae6c3ef6962ce > # bad: [1966391fa576e1fb2701be8bcca197d8f72737b7] mm/migrate.c: > attach_page_private already does the get_page > git bisect bad 1966391fa576e1fb2701be8bcca197d8f72737b7 > # good: [43c8546bcd854806736d8a635a0d696504dd4c21] drm/amdgpu: Add a UAPI > flag for user to call mem_sync > git bisect good 43c8546bcd854806736d8a635a0d696504dd4c21 > # good: [6cf991611bc72c077f0cc64e23987341ad7ef41e] Merge tag > 'drm-intel-next-2020-05-15' of git://anongit.freedesktop.org/drm/drm-intel > into drm-next > git bisect good 6cf991611bc72c077f0cc64e23987341ad7ef41e > # bad: [dc455f4c888365595c0a13da445e092422d55b8d] drm/nouveau/dispnv50: fix > runtime pm imbalance on error > git bisect bad dc455f4c888365595c0a13da445e092422d55b8d > # bad: [2dd4d163cd9c15432524aa9863155bc03a821361] drm/nouveau: remove > open-coded version of remove_conflicting_pci_framebuffers() > git bisect bad 2dd4d163cd9c15432524aa9863155bc03a821361 > # good: [c41219fda6e04255c44d37fd2c0d898c1c46abf1] Merge tag > 'drm-intel-next-fixes-2020-05-20' of > git://anongit.freedesktop.org/drm
Re: [Nouveau] NVIDIA GP107 (137000a1) - acr: failed to load firmware
On Thu, Jun 4, 2020 at 12:04 PM Zeno Davatz wrote: > > Thank you, Ilia > > On Thu, Jun 4, 2020 at 5:25 PM Ilia Mirkin wrote: > > > There's a lot more firmware files than that ... everything in the > > gp107 directory. Also this would only be necessary if nouveau is built > > into the kernel. The files just have to be available whenever nouveau > > is loaded -- if it's built in, that means the firmware has to be baked > > into the kernel too. If it's loaded from initrd, that means the > > firmware has to be in initrd. If it's loaded after boot, then the > > firmware has to be available after boot. > > For the time being I got it working by removing all nouveau selections > in "make menuconfig" and by emerging "x11-drivers/nvidia-drivers" > Version 440.82. > > Back on the latest Linux Kernel. Feels great ;). > > Linux zenogentoo 5.7.0 #84 SMP Thu Jun 4 17:47:15 CEST 2020 x86_64 > Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux Not sure why you bother asking questions when you're just going to dump nouveau anyways. This is the second time I've answered your questions on this very topic, I think it'll be the last too. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NVIDIA GP107 (137000a1) - acr: failed to load firmware
On Thu, Jun 4, 2020 at 11:16 AM Zeno Davatz wrote: > > On Thu, Jun 4, 2020 at 4:36 PM Ilia Mirkin wrote: > > > > Starting with kernel 5.6, loading nouveau without firmware (for GPUs > > where it is required, such as yours) got broken. > > > > You are loading nouveau without firmware, so it fails. > > > > The firmware needs to be available to the kernel at the time of nouveau > > loading. > > Ok, I am now trying this: > > /usr/src/linux> grep FIRMWARE /usr/src/linux/.config > CONFIG_FIRMWARE_MEMMAP=y > # CONFIG_GOOGLE_FIRMWARE is not set > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_EXTRA_FIRMWARE="nvidia/gp107/gr/sw_nonctx.bin" > # CONFIG_CYPRESS_FIRMWARE is not set > # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set > # CONFIG_FIRMWARE_EDID is not set > # CONFIG_TEST_FIRMWARE is not set There's a lot more firmware files than that ... everything in the gp107 directory. Also this would only be necessary if nouveau is built into the kernel. The files just have to be available whenever nouveau is loaded -- if it's built in, that means the firmware has to be baked into the kernel too. If it's loaded from initrd, that means the firmware has to be in initrd. If it's loaded after boot, then the firmware has to be available after boot. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NVIDIA GP107 (137000a1) - acr: failed to load firmware
Starting with kernel 5.6, loading nouveau without firmware (for GPUs where it is required, such as yours) got broken. You are loading nouveau without firmware, so it fails. The firmware needs to be available to the kernel at the time of nouveau loading. Cheers, -ilia On Thu, Jun 4, 2020 at 10:24 AM Zeno Davatz wrote: > > Hi > > With Kernel 5.7 I am still getting this, while booting: > > ~> uname -a > Linux zenogentoo 5.7.0 #80 SMP Thu Jun 4 16:10:03 CEST 2020 x86_64 > Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux > ~> dmesg |grep nouveau > [0.762872] nouveau :05:00.0: NVIDIA GP107 (137000a1) > [0.875311] nouveau :05:00.0: bios: version 86.07.42.00.4a > [0.875681] nouveau :05:00.0: acr: failed to load firmware > [0.875780] nouveau :05:00.0: acr: failed to load firmware > [0.875881] nouveau :05:00.0: acr ctor failed, -2 > [0.875980] nouveau: probe of :05:00.0 failed with error -2 > > Old thread is here: https://lkml.org/lkml/2020/4/3/775 > > My Linxu-Firmware is: linux-firmware-20200421 > > This used to work fine with Kernel 5.5. > > Please CC me for replies. > > best > Zeno > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 5.5 kernel: using nouveau or something else just long enough to turn off Quadro RTX 4000 Mobile for hybrid graphics?
On Fri, May 29, 2020 at 2:35 PM Marc MERLIN wrote: > > Howdy, > > So, I have a Thinkpad P70 with hybrid graphics. > 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] > (rev a2) > that one works fine, I can use i915 for the main screen, and nouveau to > display on the external ports (external ports are only wired to nvidia > chip, so it's impossible to use them without turning the nvidia chip > on). > > I now got a newer P73 also with the same hybrid graphics (setup as such > in the bios). It runs fine with i915, and I don't need to use external > display with nouveau for now (it almost works, but I only see the mouse > cursor on the external screen, no window or anything else can get > displayed, very weird). > 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX > 4000 Mobile / Max-Q] (rev a1) > > What I need for now is either nouveau, or bbswitch if it still works to > turn the nvidia chip off every time I power on/reboot/plug/unplug > external power. > if I don't load the nouveau module, I get this in powertop: > Bad Runtime PM for PCI Device NVIDIA Corporation TU104GLM [Quadro > RTX 4000 Mobile / Max-Q] > powertop cannot really turn it off and I get > The battery reports a discharge rate of 63.0 W > > If I load the nouveau driver, the chip gets turned off (great), but it's > unstable and hard crashes my laptop when I plug/unplug it from power > after a few times. > This is what I got in my logs after the last crash: > intel-lpss :00:15.0: power state changed by ACPI to D3cold > intel-lpss :00:15.1: power state changed by ACPI to D3cold > snd_hda_intel :00:1f.3: PME# enabled > intel-lpss :00:1e.0: power state changed by ACPI to D3cold > snd_hda_intel :00:1f.3: power state changed by ACPI to D3hot > xhci_hcd :01:00.2: PME# enabled > nvidia-gpu :01:00.3: PME# enabled > pcieport :05:00.0: PME# enabled > xhci_hcd :2c:00.0: PME# enabled > pcieport :05:02.0: PME# enabled > pcieport :04:00.0: PME# enabled > pcieport :00:1c.0: PME# enabled > pcieport :00:1c.0: power state changed by ACPI to D3cold > nouveau :01:00.0: power state changed by ACPI to D3cold > pcieport :00:01.0: PME# enabled > pcieport :00:01.0: power state changed by ACPI to D3cold > > I am using TLP to manage battery use, the driver might not like things > getting turned off to save power > (although when it works, I can get the laptop down to 10W) > > Any suggestions on my best way to just keep the nvidia chip off reliably? > nouveau? bbswitch? other? > (and before you ask, no, you cannot turn it off in the bios, it's hybrid or > nvidia only) > > > If that helps, here is what I got when I tried to use hybrid graphics to > power an external > monitor (just pasting for completeness, I don't need this to work for now) > > pci :01:00.0: optimus capabilities: enabled, status dynamic power, hda > bios codec supported > VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle > nouveau: detected PR support, will not use DSM > nouveau :01:00.0: runtime IRQ mapping not provided by arch > nouveau :01:00.0: NVIDIA TU104 (164000a1) > nouveau :01:00.0: bios: version 90.04.4d.00.2c > nouveau :01:00.0: enabling bus mastering > nouveau :01:00.0: fb: 8192 MiB GDDR6 > vga_switcheroo: enabled > [TTM] Zone kernel: Available graphics memory: 32730618 KiB > [TTM] Zone dma32: Available graphics memory: 2097152 KiB > [TTM] Initializing pool allocator > [TTM] Initializing DMA pool allocator > nouveau :01:00.0: DRM: VRAM: 8192 MiB > nouveau :01:00.0: DRM: GART: 536870912 MiB > nouveau :01:00.0: DRM: BIT table 'A' not found > nouveau :01:00.0: DRM: BIT table 'L' not found > nouveau :01:00.0: DRM: TMDS table version 2.0 > nouveau :01:00.0: DRM: DCB version 4.1 > nouveau :01:00.0: DRM: DCB outp 00: 02800f66 04600020 > nouveau :01:00.0: DRM: DCB outp 01: 02011f52 00020010 > nouveau :01:00.0: DRM: DCB outp 02: 01022f36 04600010 > nouveau :01:00.0: DRM: DCB outp 03: 04033f76 04600010 > nouveau :01:00.0: DRM: DCB outp 04: 04044f86 04600020 > nouveau :01:00.0: DRM: DCB conn 00: 00020047 > nouveau :01:00.0: DRM: DCB conn 01: 00010161 > nouveau :01:00.0: DRM: DCB conn 02: 1248 > nouveau :01:00.0: DRM: DCB conn 03: 01000348 > nouveau :01:00.0: DRM: DCB conn 04: 02000471 > nouveau :01:00.0: DRM: failed to create kernel channel, -22 > nouveau :01:00.0: DRM: MM: using COPY for buffer copies > nouveau :01:00.0: DRM: unknown connector type 48 > nouveau :01:00.0: DRM: unknown connector type 48 > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [drm] Driver supports precise vblank timestamp query. > memmap_init_zone_device initialised 2097152 pages in 16ms > nouveau :01:00.0: DRM: DMEM: registered 8192MB of device memory > nouveau :01:00.0: DRM: allocated 2560x1600 fb: 0x20, bo > 18f13ee1 > nouveau 000
Re: [Nouveau] [PATCH] nouveau: add fbdev dependency
Isn't this already fixed by
https://cgit.freedesktop.org/drm/drm/commit/?id=7dbbdd37f2ae7dd4175ba3f86f4335c463b18403
On Wed, May 27, 2020 at 9:43 AM Arnd Bergmann wrote:
>
> Calling directly into the fbdev stack only works when the
> fbdev layer is built into the kernel as well, or both are
> loadable modules:
>
> drivers/gpu/drm/nouveau/nouveau_drm.o: in function `nouveau_drm_probe':
> nouveau_drm.c:(.text+0x1f90): undefined reference to
> `remove_conflicting_pci_framebuffers'
>
> The change seems to have been intentional, so add an explicit
> dependency here but allow it to still be compiled if FBDEV
> is completely disabled.
>
> Fixes: 2dd4d163cd9c ("drm/nouveau: remove open-coded version of
> remove_conflicting_pci_framebuffers()")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/nouveau/Kconfig | 1 +
> drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
> index 980ed09bd7f6..8c640f003358 100644
> --- a/drivers/gpu/drm/nouveau/Kconfig
> +++ b/drivers/gpu/drm/nouveau/Kconfig
> @@ -18,6 +18,7 @@ config DRM_NOUVEAU
> select THERMAL if ACPI && X86
> select ACPI_VIDEO if ACPI && X86
> select SND_HDA_COMPONENT if SND_HDA_CORE
> + depends on FBDEV || !FBDEV
> help
> Choose this option for open-source NVIDIA support.
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index eb10c80ed853..e8560444ab57 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -697,7 +697,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> nvkm_device_del(&device);
>
> /* Remove conflicting drivers (vesafb, efifb etc). */
> - ret = remove_conflicting_pci_framebuffers(pdev, "nouveaufb");
> + if (IS_ENABLED(CONFIG_FBDEV))
> + ret = remove_conflicting_pci_framebuffers(pdev, "nouveaufb");
> if (ret)
> return ret;
>
> --
> 2.26.2
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau
Hi Andreas, On Mon, May 18, 2020 at 9:56 AM Andreas Schwab wrote: > > On Mai 18 2020, Michael Ellerman wrote: > > > The old drivers may be crufty but they presumably have been tested by > > people and at least somewhat work. > > I can confirm that the nvidia fbdev driver is working perfectly fine. > > > I gave it a quick spin on a G5 I have access to and dmesg has a bunch of > > errors in it (see below). I can't actually tell if the display is > > working because the machine is remote, and I can't go and check it at > > the moment because the office is closed. > > The nouveau driver is completely borked. > > [2.299204] nouveau :f0:10.0: NVIDIA NV34 (034100a2) > [2.363100] nouveau :f0:10.0: bios: version 04.34.20.19.00 > [2.363273] nouveau :f0:10.0: bios: OOB 1 0962 0962 > [2.363323] nouveau :f0:10.0: bios: OOB 1 0966 0966 > [2.363332] nouveau :f0:10.0: bios: OOB 1 0963 0963 > [2.363341] nouveau :f0:10.0: bios: OOB 1 0964 0964 > [2.363387] nouveau :f0:10.0: bios: OOB 1 096a 096a > [2.363396] nouveau :f0:10.0: bios: OOB 1 0967 0967 > [2.363405] nouveau :f0:10.0: bios: OOB 1 0968 0968 > [2.363453] nouveau :f0:10.0: bios: OOB 1 096e 096e > [2.363462] nouveau :f0:10.0: bios: OOB 1 096b 096b > [2.363471] nouveau :f0:10.0: bios: OOB 1 096c 096c > [2.363516] nouveau :f0:10.0: bios: OOB 1 0972 0972 > [2.363526] nouveau :f0:10.0: bios: OOB 1 096f 096f > [2.363534] nouveau :f0:10.0: bios: OOB 1 0970 0970 > [2.363580] nouveau :f0:10.0: bios: OOB 1 0976 0976 > [2.363589] nouveau :f0:10.0: bios: OOB 1 0973 0973 > [2.363597] nouveau :f0:10.0: bios: OOB 1 0974 0974 > [2.363643] nouveau :f0:10.0: bios: OOB 1 097a 097a > [2.363652] nouveau :f0:10.0: bios: OOB 1 0977 0977 > [2.363661] nouveau :f0:10.0: bios: OOB 1 0978 0978 > [2.363709] nouveau :f0:10.0: bios: OOB 1 097e 097e > [2.363718] nouveau :f0:10.0: bios: OOB 1 097b 097b > [2.363727] nouveau :f0:10.0: bios: OOB 1 097c 097c > [2.363772] nouveau :f0:10.0: bios: OOB 1 0982 0982 > [2.363781] nouveau :f0:10.0: bios: OOB 1 097f 097f > [2.363790] nouveau :f0:10.0: bios: OOB 1 0980 0980 > [2.363836] nouveau :f0:10.0: bios: OOB 1 0986 0986 > [2.363845] nouveau :f0:10.0: bios: OOB 1 0983 0983 > [2.363854] nouveau :f0:10.0: bios: OOB 1 0984 0984 > [2.363900] nouveau :f0:10.0: bios: OOB 1 098a 098a > [2.363909] nouveau :f0:10.0: bios: OOB 1 0987 0987 > [2.363918] nouveau :f0:10.0: bios: OOB 1 0988 0988 > [2.363965] nouveau :f0:10.0: bios: OOB 1 098e 098e > [2.363974] nouveau :f0:10.0: bios: OOB 1 098b 098b > [2.363983] nouveau :f0:10.0: bios: OOB 1 098c 098c > [2.364029] nouveau :f0:10.0: bios: OOB 1 0992 0992 > [2.364038] nouveau :f0:10.0: bios: OOB 1 098f 098f > [2.364047] nouveau :f0:10.0: bios: OOB 1 0990 0990 > [2.364383] nouveau :f0:10.0: gpio: GPU is missing power, check its > power cables. Boot with nouveau.config=NvPowerChecks=0 to disable. > [2.364402] nouveau :f0:10.0: gpio: init failed, -22 > [2.364431] nouveau :f0:10.0: init failed with -22 > [2.364438] nouveau: DRM-master::0080: init failed with -22 > [2.364450] nouveau :f0:10.0: DRM-master: Device allocation failed: -22 > [2.365268] nouveau: probe of :f0:10.0 failed with error -22 If you're interested in providing some further info, could you attach your VBIOS? I did, at one point, a long time ago, get a NV34 G5 PowerMac7,3 working fine with nouveau. I'm curious if something in your VBIOS is different, or if the logic has regressed. (It would have been working in 4.4 or so.) You can find the VBIOS in of, it's called "NVDA,BMP", should be accessible in procfs or sysfs somewhere, but not 100% sure where. (From an old guide, /proc/device-tree/pci@f000/NVDA,Parent@10/NVDA,BMP seems to be it, possibly with some local adjustments.) Thanks, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes
On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote: > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c > b/drivers/gpu/drm/nouveau/nouveau_connector.c > index 43bcbb6d73c4..6dae00da5d7e 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_connector.c > +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c > @@ -1065,7 +1065,7 @@ nouveau_connector_mode_valid(struct drm_connector > *connector, > return get_slave_funcs(encoder)->mode_valid(encoder, mode); > case DCB_OUTPUT_DP: > if (mode->flags & DRM_MODE_FLAG_INTERLACE && > - !nv_encoder->dp.caps.interlace) > + !nv_encoder->caps.dp_interlace) > return MODE_NO_INTERLACE; > > max_clock = nv_encoder->dp.link_nr; You probably meant for this hunk to go into an earlier patch. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
I don't think that logic has changed in over a year, nor do I expect it will in the future, unless someone comes in and does the work to figure out what's wrong. If that's not you, then you have to hope there will be someone else interested in running a desktop GPU on an arm-based board. On Fri, May 8, 2020 at 11:13 AM Milan Buška wrote: > > Thanks for the info. > I'll pull it out in a year and try it. > > Greeting > > pá 8. 5. 2020 v 15:27 odesílatel Ilia Mirkin napsal: > > > > On Fri, May 8, 2020 at 4:34 AM Milan Buška wrote: > > > > > > Good day. > > > I'm not a programmer, so I don't understand. > > > > > > Just a question: > > > What's wrong => > > > => nouveau driver > > > => pcie driver > > > => graphics card > > > > > > It will help me save unnecessary lost time. > > > > Most likely the issue is in nouveau. There's a much smaller likelihood > > that the issue is with e.g. the iommu/dma-api implementation. > > > > Cheers, > > > > -ilia > > > > -- > > Remember, no question is too stupid and no problem too small >-- We've all been beginners ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
On Fri, May 8, 2020 at 4:34 AM Milan Buška wrote: > > Good day. > I'm not a programmer, so I don't understand. > > Just a question: > What's wrong => > => nouveau driver > => pcie driver > => graphics card > > It will help me save unnecessary lost time. Most likely the issue is in nouveau. There's a much smaller likelihood that the issue is with e.g. the iommu/dma-api implementation. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
On Thu, May 7, 2020 at 12:11 AM Milan Buska wrote: > > On 20-05-06 18:53:00, Ilia Mirkin wrote: > > On Wed, May 6, 2020 at 5:59 PM Milan Buska wrote: > > > > > > On 20-05-06 17:12:44, Ilia Mirkin wrote: > > > > You need both VRAM *and* UNCACHED. Separate them with a | > > > > > > > > On Wed, May 6, 2020 at 5:10 PM Milan Buska > > > > wrote: > > > > > > > > > > On 20-05-06 11:51:35, Ilia Mirkin wrote: > > > > > > On Wed, May 6, 2020 at 10:42 AM Ilia Mirkin > > > > > > wrote: > > > > > > > On Wed, May 6, 2020 at 10:39 AM Lucas Stach > > > > > > > wrote: > > > > > > > > > > [ 17.146929] nouveau :01:00.0: DRM: core notifier > > > > > > > > > > timeout > > > > > > > > > > [ 19.146846] nouveau :01:00.0: DRM: base-0: timeout > > > > > > > > > > [ 19.147554] Console: switching to colour frame buffer > > > > > > > > > > device 240x67 > > > > > > > > > > [ 19.446311] nouveau :01:00.0: DRM: GPU lockup - > > > > > > > > > > switching to software fbcon > > > > > > > > > > [ 19.501043] nouveau :01:00.0: fb0: nouveaudrmfb > > > > > > > > > > frame buffer device > > > > > > > > > > [ 19.523471] [drm] Initialized nouveau 1.3.1 20120801 for > > > > > > > > > > :01:00.0 on minor 0 > > > > > > > > > > > > > > > > > > So that "core notifier timeout" and subsequent GPU lockup > > > > > > > > > indicate > > > > > > > > > that something's amiss. Most of the initialization was able > > > > > > > > > to be > > > > > > > > > completed, including reading EDID from your monitor (hence the > > > > > > > > > non-default resolution), but we're not seeing values change > > > > > > > > > properly / > > > > > > > > > missing notifications. I'm actually wondering if we aren't > > > > > > > > > initializing the GPU because we think it's already > > > > > > > > > initialized. Could > > > > > > > > > you boot with nouveau.config=NvForcePost=1 and see if that > > > > > > > > > helps? > > > > > > > > > > > > > > > > Note that PCIe is non-coherent on most ARM devices (including > > > > > > > > Tegra TX2 > > > > > > > > IIRC), so if the notifier BO isn't mapped as uncached memory, > > > > > > > > you > > > > > > > > probably won't see the expected notifier content, as you are > > > > > > > > reading > > > > > > > > stale cache line content. > > > > > > > > > > > > > > I *believe* that as part of getting nouveau working with the Tegra > > > > > > > in-SoC GPU, at least the fence logic was adjusted. However > > > > > > > perhaps we > > > > > > > didn't do it for notifier memory... worth checking. > > > > > > > > > > > > Hm, looks like we should be passing in TTM_PL_FLAG_UNCACHED for the > > > > > > notifier, which should cause nouveau_bo to do the right thing (by > > > > > > setting force_coherent=true in this environment): > > > > > > > > > > > > ret = nouveau_bo_new(&drm->client, 4096, 0x1000, TTM_PL_FLAG_VRAM, > > > > > > 0, 0x, NULL, NULL, &disp->sync); > > > > > > > > > > > > Milan - can you try changing that line in > > > > > > > > > > > > drivers/gpu/drm/nouveau/dispnv50/disp.c::nv50_display_create > > > > > > > > > > > > to have TTM_PL_FLAG_VRAM | TTM_PL_FLAG_UNCACHED instead for that > > > > > > nouveau_bo_new call (no need to change the later nouveau_bo_pin > > > > > > call)? > > > > > > > > > > > > Cheers, > > > > > > > > > > > > -ilia > > > > > > > > > > > > > > > > /* small shared memory area we use for notifiers and > > > > > semaphores */ > > > ret = nouveau_bo_new(&drm->client, 4096, 0x1000, > > > TTM_PL_FLAG_VRAM | TTM_PL_FLAG_UNCACHED, > > > > > > it is OK > > > > What do you mean by that? You're testing it, or that fixed it? > > > It's the same Oh well, it was worth a shot. Someone will have to debug what's going on. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
On Wed, May 6, 2020 at 10:42 AM Ilia Mirkin wrote: > On Wed, May 6, 2020 at 10:39 AM Lucas Stach wrote: > > > > [ 17.146929] nouveau :01:00.0: DRM: core notifier timeout > > > > [ 19.146846] nouveau :01:00.0: DRM: base-0: timeout > > > > [ 19.147554] Console: switching to colour frame buffer device 240x67 > > > > [ 19.446311] nouveau :01:00.0: DRM: GPU lockup - switching to > > > > software fbcon > > > > [ 19.501043] nouveau :01:00.0: fb0: nouveaudrmfb frame buffer > > > > device > > > > [ 19.523471] [drm] Initialized nouveau 1.3.1 20120801 for > > > > :01:00.0 on minor 0 > > > > > > So that "core notifier timeout" and subsequent GPU lockup indicate > > > that something's amiss. Most of the initialization was able to be > > > completed, including reading EDID from your monitor (hence the > > > non-default resolution), but we're not seeing values change properly / > > > missing notifications. I'm actually wondering if we aren't > > > initializing the GPU because we think it's already initialized. Could > > > you boot with nouveau.config=NvForcePost=1 and see if that helps? > > > > Note that PCIe is non-coherent on most ARM devices (including Tegra TX2 > > IIRC), so if the notifier BO isn't mapped as uncached memory, you > > probably won't see the expected notifier content, as you are reading > > stale cache line content. > > I *believe* that as part of getting nouveau working with the Tegra > in-SoC GPU, at least the fence logic was adjusted. However perhaps we > didn't do it for notifier memory... worth checking. Hm, looks like we should be passing in TTM_PL_FLAG_UNCACHED for the notifier, which should cause nouveau_bo to do the right thing (by setting force_coherent=true in this environment): ret = nouveau_bo_new(&drm->client, 4096, 0x1000, TTM_PL_FLAG_VRAM, 0, 0x, NULL, NULL, &disp->sync); Milan - can you try changing that line in drivers/gpu/drm/nouveau/dispnv50/disp.c::nv50_display_create to have TTM_PL_FLAG_VRAM | TTM_PL_FLAG_UNCACHED instead for that nouveau_bo_new call (no need to change the later nouveau_bo_pin call)? Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
On Wed, May 6, 2020 at 10:39 AM Lucas Stach wrote: > > Am Mittwoch, den 06.05.2020, 10:26 -0400 schrieb Ilia Mirkin: > > [please keep list cc'd in your replies] > > > > On Wed, May 6, 2020 at 10:15 AM Milan Buška wrote: > > > [0.00] Linux version 5.6.10-zotac (root@saux) (gcc version 9.3.0 > > > (SAUX Aarch64)) #1 SMP PREEMPT Tue May 5 22:16:40 CEST 2020 > > > [0.00] Machine model: NVIDIA Jetson TX2 Developer Kit > > > > [...] > > > > > [3.965934] tegra-pcie 10003000.pcie: Adding to iommu group 5 > > > [3.966435] tegra-pcie 10003000.pcie: 4x1, 1x1 configuration > > > [3.968057] tegra-pcie 10003000.pcie: probing port 0, using 4 lanes > > > [3.970121] tegra-pcie 10003000.pcie: probing port 1, using 0 lanes > > > [3.972183] tegra-pcie 10003000.pcie: probing port 2, using 1 lanes > > > [5.260316] tegra-pcie 10003000.pcie: link 1 down, ignoring > > > [6.479410] tegra-pcie 10003000.pcie: link 2 down, ignoring > > > [6.479579] tegra-pcie 10003000.pcie: PCI host bridge to bus :00 > > > [6.479602] pci_bus :00: root bus resource [io 0x-0x] > > > [6.479627] pci_bus :00: root bus resource [mem > > > 0x5010-0x57ff] > > > [6.479646] pci_bus :00: root bus resource [mem > > > 0x5800-0x7fff pref] > > > [6.479668] pci_bus :00: root bus resource [bus 00-ff] > > > [6.479850] pci :00:01.0: [10de:10e5] type 01 class 0x060400 > > > [6.479887] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x4 may corrupt adjacent RW1C bits > > > [6.479916] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x4 may corrupt adjacent RW1C bits > > > [6.479993] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x3e may corrupt adjacent RW1C bits > > > [6.480041] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x52 may corrupt adjacent RW1C bits > > > [6.480118] pci :00:01.0: PME# supported from D0 D1 D2 D3hot D3cold > > > [6.480141] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x4c may corrupt adjacent RW1C bits > > > [6.482485] pci :00:01.0: bridge configuration invalid ([bus > > > 00-00]), reconfiguring > > > [6.482521] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x3e may corrupt adjacent RW1C bits > > > [6.482576] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x3e may corrupt adjacent RW1C bits > > > [6.482607] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x3e may corrupt adjacent RW1C bits > > > [6.482635] pci_bus :00: 2-byte config write to :00:01.0 > > > offset 0x6 may corrupt adjacent RW1C bits > > > [6.482794] pci :01:00.0: [10de:128b] type 00 class 0x03 > > > [6.482931] pci :01:00.0: reg 0x10: [mem 0x-0x00ff] > > > [6.482976] pci :01:00.0: reg 0x14: [mem 0x-0x07ff > > > 64bit pref] > > > [6.483022] pci :01:00.0: reg 0x1c: [mem 0x-0x01ff > > > 64bit pref] > > > [6.483056] pci :01:00.0: reg 0x24: [io 0x-0x007f] > > > [6.483087] pci :01:00.0: reg 0x30: [mem 0x-0x0007 > > > pref] > > > [6.483313] pci :01:00.0: 4.000 Gb/s available PCIe bandwidth, > > > limited by 5 GT/s x1 link at :00:01.0 (capable of 32.000 Gb/s with 5 > > > GT/s x8 link) > > > [6.483463] pci :01:00.0: vgaarb: VGA device added: > > > decodes=io+mem,owns=none,locks=none > > > [6.483556] pci :01:00.1: [10de:0e0f] type 00 class 0x040300 > > > [6.483648] pci :01:00.1: reg 0x10: [mem 0x-0x3fff] > > > [6.485344] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > > > [6.485368] pci_bus :00: 1-byte config write to :00:01.0 > > > offset 0x1a may corrupt adjacent RW1C bits > > > [6.485411] pci :00:01.0: BAR 15: assigned [mem > > > 0x5800-0x63ff 64bit pref] > > > [6.485431] pci :00:01.0: BAR 14: assigned [mem > > > 0x5080-0x51ff] > > > [6.485448] pci :00:01.0: BAR 13: assigned [io 0x1000-0x1fff] > > > [6.485471] pci :01:00.0: BAR 1: assigned [mem > > > 0x5800-0x5fff 64bit pref] > > > [6.485510] pci :01:00.0: BAR 3: assigned [mem > > > 0x6000-0x61f
Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
[please keep list cc'd in your replies] On Wed, May 6, 2020 at 10:15 AM Milan Buška wrote: > [0.00] Linux version 5.6.10-zotac (root@saux) (gcc version 9.3.0 > (SAUX Aarch64)) #1 SMP PREEMPT Tue May 5 22:16:40 CEST 2020 > [0.00] Machine model: NVIDIA Jetson TX2 Developer Kit [...] > [3.965934] tegra-pcie 10003000.pcie: Adding to iommu group 5 > [3.966435] tegra-pcie 10003000.pcie: 4x1, 1x1 configuration > [3.968057] tegra-pcie 10003000.pcie: probing port 0, using 4 lanes > [3.970121] tegra-pcie 10003000.pcie: probing port 1, using 0 lanes > [3.972183] tegra-pcie 10003000.pcie: probing port 2, using 1 lanes > [5.260316] tegra-pcie 10003000.pcie: link 1 down, ignoring > [6.479410] tegra-pcie 10003000.pcie: link 2 down, ignoring > [6.479579] tegra-pcie 10003000.pcie: PCI host bridge to bus :00 > [6.479602] pci_bus :00: root bus resource [io 0x-0x] > [6.479627] pci_bus :00: root bus resource [mem 0x5010-0x57ff] > [6.479646] pci_bus :00: root bus resource [mem 0x5800-0x7fff > pref] > [6.479668] pci_bus :00: root bus resource [bus 00-ff] > [6.479850] pci :00:01.0: [10de:10e5] type 01 class 0x060400 > [6.479887] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x4 may corrupt adjacent RW1C bits > [6.479916] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x4 may corrupt adjacent RW1C bits > [6.479993] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x3e may corrupt adjacent RW1C bits > [6.480041] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x52 may corrupt adjacent RW1C bits > [6.480118] pci :00:01.0: PME# supported from D0 D1 D2 D3hot D3cold > [6.480141] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x4c may corrupt adjacent RW1C bits > [6.482485] pci :00:01.0: bridge configuration invalid ([bus 00-00]), > reconfiguring > [6.482521] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x3e may corrupt adjacent RW1C bits > [6.482576] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x3e may corrupt adjacent RW1C bits > [6.482607] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x3e may corrupt adjacent RW1C bits > [6.482635] pci_bus :00: 2-byte config write to :00:01.0 offset > 0x6 may corrupt adjacent RW1C bits > [6.482794] pci :01:00.0: [10de:128b] type 00 class 0x03 > [6.482931] pci :01:00.0: reg 0x10: [mem 0x-0x00ff] > [6.482976] pci :01:00.0: reg 0x14: [mem 0x-0x07ff 64bit > pref] > [6.483022] pci :01:00.0: reg 0x1c: [mem 0x-0x01ff 64bit > pref] > [6.483056] pci :01:00.0: reg 0x24: [io 0x-0x007f] > [6.483087] pci :01:00.0: reg 0x30: [mem 0x-0x0007 pref] > [6.483313] pci :01:00.0: 4.000 Gb/s available PCIe bandwidth, limited > by 5 GT/s x1 link at :00:01.0 (capable of 32.000 Gb/s with 5 GT/s x8 link) > [6.483463] pci :01:00.0: vgaarb: VGA device added: > decodes=io+mem,owns=none,locks=none > [6.483556] pci :01:00.1: [10de:0e0f] type 00 class 0x040300 > [6.483648] pci :01:00.1: reg 0x10: [mem 0x-0x3fff] > [6.485344] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > [6.485368] pci_bus :00: 1-byte config write to :00:01.0 offset > 0x1a may corrupt adjacent RW1C bits > [6.485411] pci :00:01.0: BAR 15: assigned [mem 0x5800-0x63ff > 64bit pref] > [6.485431] pci :00:01.0: BAR 14: assigned [mem 0x5080-0x51ff] > [6.485448] pci :00:01.0: BAR 13: assigned [io 0x1000-0x1fff] > [6.485471] pci :01:00.0: BAR 1: assigned [mem 0x5800-0x5fff > 64bit pref] > [6.485510] pci :01:00.0: BAR 3: assigned [mem 0x6000-0x61ff > 64bit pref] > [6.485547] pci :01:00.0: BAR 0: assigned [mem 0x5100-0x51ff] > [6.485569] pci :01:00.0: BAR 6: assigned [mem 0x5080-0x5087 > pref] > [6.485588] pci :01:00.1: BAR 0: assigned [mem 0x5088-0x50883fff] > [6.485610] pci :01:00.0: BAR 5: assigned [io 0x1000-0x107f] > [6.485631] pci :00:01.0: PCI bridge to [bus 01] > [6.485648] pci :00:01.0: bridge window [io 0x1000-0x1fff] > [6.485668] pci :00:01.0: bridge window [mem 0x5080-0x51ff] > [6.485691] pci :00:01.0: bridge window [mem 0x5800-0x63ff > 64bit pref] > [6.485760] pci :00:01.0: nv_msi_ht_cap_quirk didn't locate host bridge > [6.485857] pcieport :00:01.0: Adding to iommu group 5 > [6.485930] pcieport :00:01.0: enabling device ( -> 0003) > [6.486051] pcieport :00:01.0: PME: Signaling with IRQ 40 > [6.486378] pcieport :00:01.0: AER: enabled with IRQ 40 > [6.486714] pci :01:00.1: D0 power state depends on :01:00.0 Hm, I can't say that I
Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
In general it should be possible. If you're having issues, please include dmesg. One issue that has come up is that the PCIe controllers on such boards have very narrow memory windows, not enough to map certain (required) BARs of NVIDIA GPUs (or other GPUs, I'd expect). This comes up in dmesg with PCI-related errors. Cheers, -ilia On Wed, May 6, 2020 at 9:53 AM Milan Buška wrote: > > Hi to all. > I'm experimenting with running a > https://www.zotac.com/us/product/graphics_card/geforce%C2%AE-gt-710-1gb-pcie-x-1 > card on an Nvidia Jetson TX2 arm64 device. > Possible? > Linux kernel aarch64 5.6.10. > Because Nvidia did not list drivers for this architecture, I'm experimenting > with a nouveau driver. > The Jetson TX2 has a default driver for the host1x framebuffer for output > from the board via HDMI. > I changed the video kernel parameter to nouveau. Booting the system OK only > there is no output on the monitor. > The device can only be controlled via the serial console. > Can anyone advise me where to start setting up - (if something needs to be > set up) > > Greeting > > Milan Buška > > -- > > Remember, no question is too stupid and no problem too small >-- We've all been beginners > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] problems with NVS310
Oh right. Wayland. Not sure how one gets the EDID out there... On Tue, May 5, 2020 at 12:50 PM Alberto Sentieri <2...@tripolho.com> wrote: > > I guess the DVI adapter is passive. > > $ xrandr --props > Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 8192 x 8192 > XWAYLAND1 connected 1920x1080+0+0 (normal left inverted right x axis y > axis) 510mm x 290mm > non-desktop: 0 > supported: 0, 1 > 1920x1080 59.96*+ > XWAYLAND4 connected 2560x1440+1920+0 (normal left inverted right x axis > y axis) 600mm x 340mm > non-desktop: 0 > supported: 0, 1 > 2560x1440 59.91*+ > > On 5/5/20 11:17 AM, Ilia Mirkin wrote: > > On Tue, May 5, 2020 at 11:02 AM Alberto Sentieri <2...@tripolho.com> wrote: > >> I have two monitors connected to the PC. One is an AOC 23" (1920 x 1080) > >> and the other is a BenQ 27" (2560 x 1440). Nothing special about them. > >> BenQ has a display port and the AOC uses some sort of DVI adapter. > > Do you know if the DVI adapter is active or passive? (If you include > > the EDID, that should become apparent. It should be visible in "xrandr > > --props") > > > >> I have this event many times and I captured dmesg twice. At least at one > >> time I captured dmesg my computer was under high load: it had about 15 > >> to 20 windows opened (spreadsheets, Thunderbird, Firefox, virtual > >> machines under virtual box), there was a lot of disk activity and I was > >> as trying to capture a screenshot from Firefox using the screenshot > >> tool. I could not make everything fit into one screen, so I hit F11 > >> (while in Firefox), captured what I needed (now it fit), and when I > >> pressed F11 again to make Firefox come back to a regular window, it > >> locked: I could not move the mouse and caps lock led was frozen. > > Hm, moving between full screen/not is at least a page-flip if wayland > > is being used. I guess it's plausible. > > > >-ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] problems with NVS310
On Tue, May 5, 2020 at 11:02 AM Alberto Sentieri <2...@tripolho.com> wrote: > > I have two monitors connected to the PC. One is an AOC 23" (1920 x 1080) > and the other is a BenQ 27" (2560 x 1440). Nothing special about them. > BenQ has a display port and the AOC uses some sort of DVI adapter. Do you know if the DVI adapter is active or passive? (If you include the EDID, that should become apparent. It should be visible in "xrandr --props") > > I have this event many times and I captured dmesg twice. At least at one > time I captured dmesg my computer was under high load: it had about 15 > to 20 windows opened (spreadsheets, Thunderbird, Firefox, virtual > machines under virtual box), there was a lot of disk activity and I was > as trying to capture a screenshot from Firefox using the screenshot > tool. I could not make everything fit into one screen, so I hit F11 > (while in Firefox), captured what I needed (now it fit), and when I > pressed F11 again to make Firefox come back to a regular window, it > locked: I could not move the mouse and caps lock led was frozen. Hm, moving between full screen/not is at least a page-flip if wayland is being used. I guess it's plausible. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] problems with NVS310
The warning you included happens when we're trying to execute a VBIOS script as part of DP training. Can you include your vbios? It should be available at /sys/kernel/debug/dri/0/vbios.rom Also, can you confirm how your monitors are connected to the card (and e.g. what resolution they are, anything else "funny" about them)? Finally, this warning might not have anything to do with the hang. It doesn't sound like you're changing modes or plugging/unplugging monitors when this happens... anyways, I guess GNOME3 and Firefox are both making much heavier use of 3d accel, which provides more opportunities for things to go wrong. However the log you provided does not appear to be an indication of that. Cheers, -ilia On Mon, May 4, 2020 at 11:47 PM Alberto Sentieri <2...@tripolho.com> wrote: > > I have a Nvidia NVS310 installed in my Linux computer for a few years. > It works well with the Nvidia driver, and not so well with the Linux > nouveau driver. The Nvidia NVS310 has never worked well with Linux. In > the beginning (many years ago) I decided to install Nvidia proprietary > drivers, but every kernel upgrade would require an additional effort to > have the driver working. That was enough for me to try the standard > non-proprietary driver again. > > Lately, with Debian stretch (and Mate), things got sort of stable with > the nouveau driver, and I was getting one frozen screen every few > months, which was kind of acceptable. A couple of weeks ago I upgrade to > Debian buster (GNOME3) and the nightmare is back: I get a frozen screen > at leas once a day. A simple F11 pressed on Firefox could cause the > freeze, but there other things, which I could not determine, that also > cause the freeze. The freeze is only a graphic freeze, I mean, I can ssh > into the machine from my laptop, stop all services and shut it down, or > restart it. But I could not figure out a way of restarting the video > without a reboot. And every freeze usually means losing something, and > losing many minutes. > > Any suggestions? > > Here is dmesg in one of the freezes: > > [23664.639186] WARNING: CPU: 3 PID: 7223 at > drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:172 > init_rdauxr+0xf4/0x130 [nouveau] > [23664.639187] Modules linked in: nfnetlink cfg80211 fuse rfcomm arc4 > md4 sha512_ssse3 sha512_generic nls_utf8 cifs ccm dns_resolver fscache > 8021q garp mrp bridge stp llc vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) > cmac bnep intel_rapl snd_hda_codec_hdmi btusb btrtl btbcm > x86_pkg_temp_thermal btintel intel_powerclamp bluetooth nls_ascii > nls_cp437 coretemp vfat fat kvm_intel jitterentropy_rng kvm > snd_hda_codec_realtek snd_hda_codec_generic drbg irqbypass > crct10dif_pclmul ansi_cprng crc32_pclmul snd_hda_intel > ghash_clmulni_intel joydev ecdh_generic snd_hda_codec intel_cstate > snd_hda_core efi_pstore snd_hwdep snd_pcm eeepc_wmi asus_wmi snd_timer > intel_uncore mei_me pcc_cpufreq snd sparse_keymap iTCO_wdt mei > intel_rapl_perf rfkill efivars wmi_bmof pcspkr soundcore sg > iTCO_vendor_support evdev firewire_sbp2 > [23664.639207] parport_pc ppdev lp parport efivarfs ip_tables x_tables > autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb > hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid sr_mod cdrom > sd_mod nouveau crc32c_intel video i2c_algo_bit mxm_wmi xhci_pci ttm ahci > xhci_hcd libahci drm_kms_helper ehci_pci aesni_intel ehci_hcd libata > aes_x86_64 drm crypto_simd usbcore cryptd e1000e glue_helper scsi_mod > firewire_ohci i2c_i801 firewire_core lpc_ich mfd_core crc_itu_t > usb_common wmi button > [23664.639224] CPU: 3 PID: 7223 Comm: kworker/u24:1 Tainted: G > OE 4.19.0-8-amd64 #1 Debian 4.19.98-1+deb10u1 > [23664.639225] Hardware name: System manufacturer System Product > Name/P9X79, BIOS 4502 10/15/2013 > [23664.639254] Workqueue: nvkm-disp gf119_disp_super [nouveau] > [23664.639275] RIP: 0010:init_rdauxr+0xf4/0x130 [nouveau] > [23664.639276] Code: e1 48 89 ef ba 09 00 00 00 be 01 00 00 00 e8 e3 9c > 03 00 85 c0 75 27 80 7c 24 0f 01 74 0e 48 c7 c7 10 bf 8e c0 e8 7a b9 b8 > dc <0f> 0b 48 89 ef e8 12 9a 03 00 0f b6 44 24 0e e9 39 ff ff ff 48 89 > [23664.639277] RSP: 0018:a53483adfc08 EFLAGS: 00010246 > [23664.639279] RAX: 0024 RBX: a53483adfc90 RCX: > > [23664.639280] RDX: RSI: 9a2bff8d66b8 RDI: > 9a2bff8d66b8 > [23664.639281] RBP: 9a2bfb86e800 R08: 0571 R09: > 0007 > [23664.639282] R10: R11: 9e7f46ed R12: > 0102 > [23664.639283] R13: 9a2bfbbb3b00 R14: 0020 R15: > 00df > [23664.639284] FS: () GS:9a2bff8c() > knlGS: > [23664.639285] CS: 0010 DS: ES: CR0: 80050033 > [23664.639286] CR2: 7f9acaa452c4 CR3: 000633e0a002 CR4: > 000606e0 > [23664.639287] Call Trace: > [23664.639310] init_auxch+0xf6/0x180 [nouveau] > [23664.639331] nvbios_exec+0x45/0xd0 [nouv
Re: [Nouveau] [PATCH] drm/nouveau/dispnv04: Remove dead code
On Fri, May 1, 2020 at 9:15 AM Souptick Joarder wrote: > > On Fri, May 1, 2020 at 2:21 AM Ilia Mirkin wrote: > > > > Interesting. I do remember seeing some snow on NV5's overlay at high > > resolutions. Wonder if it was because of this missing code... > > What was the problem ? Does enabling this dead code will fix the problem ? This "dead" code is essentially documentation. It's from the xf86-video-nv driver which was the base of the dispnv04 code. It won't compile as-is, which is why it's #if 0'd out. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/dispnv04: Remove dead code
Interesting. I do remember seeing some snow on NV5's overlay at high
resolutions. Wonder if it was because of this missing code...
On Thu, Apr 30, 2020 at 4:19 PM Souptick Joarder wrote:
>
> These are dead code since 3.10. If there is no plan to use
> it further, these can be removed forever.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 28
> 1 file changed, 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 1f08de4..ad0ef7d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -269,31 +269,11 @@ static void nv_crtc_calc_state_ext(struct drm_crtc
> *crtc, struct drm_display_mod
> horizStart = horizTotal - 5;
> horizEnd = horizTotal - 2;
> horizBlankEnd = horizTotal + 4;
> -#if 0
> - if (dev->overlayAdaptor && drm->client.device.info.family >=
> NV_DEVICE_INFO_V0_CELSIUS)
> - /* This reportedly works around some video overlay
> bandwidth problems */
> - horizTotal += 2;
> -#endif
> }
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> vertTotal |= 1;
>
> -#if 0
> - ErrorF("horizDisplay: 0x%X \n", horizDisplay);
> - ErrorF("horizStart: 0x%X \n", horizStart);
> - ErrorF("horizEnd: 0x%X \n", horizEnd);
> - ErrorF("horizTotal: 0x%X \n", horizTotal);
> - ErrorF("horizBlankStart: 0x%X \n", horizBlankStart);
> - ErrorF("horizBlankEnd: 0x%X \n", horizBlankEnd);
> - ErrorF("vertDisplay: 0x%X \n", vertDisplay);
> - ErrorF("vertStart: 0x%X \n", vertStart);
> - ErrorF("vertEnd: 0x%X \n", vertEnd);
> - ErrorF("vertTotal: 0x%X \n", vertTotal);
> - ErrorF("vertBlankStart: 0x%X \n", vertBlankStart);
> - ErrorF("vertBlankEnd: 0x%X \n", vertBlankEnd);
> -#endif
> -
> /*
> * compute correct Hsync & Vsync polarity
> */
> @@ -492,14 +472,6 @@ static void nv_crtc_calc_state_ext(struct drm_crtc
> *crtc, struct drm_display_mod
> /* Except for rare conditions I2C is enabled on the primary crtc */
> if (nv_crtc->index == 0)
> regp->crtc_eng_ctrl |= NV_CRTC_FSEL_I2C;
> -#if 0
> - /* Set overlay to desired crtc. */
> - if (dev->overlayAdaptor) {
> - NVPortPrivPtr pPriv = GET_OVERLAY_PRIVATE(dev);
> - if (pPriv->overlayCRTC == nv_crtc->index)
> - regp->crtc_eng_ctrl |= NV_CRTC_FSEL_OVERLAY;
> - }
> -#endif
>
> /* ADDRESS_SPACE_PNVM is the same as setting HCUR_ASI */
> regp->cursor_cfg = NV_PCRTC_CURSOR_CONFIG_CUR_LINES_64 |
> --
> 1.9.1
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] gp104: regression on Linux 5.6
On Thu, Apr 30, 2020 at 3:32 AM Alexey Dobriyan wrote: > > On Thu, Apr 30, 2020 at 12:15:28AM -0400, Ilia Mirkin wrote: > > Hi Alexey, > > > > On Fri, Apr 24, 2020 at 10:52 PM Alexey Dobriyan > > wrote: > > > > > > gp104 refuses to switch to "graphic" mode and show anything past > > > this line: > > > > > > fb0: switching to nouveaufb from EFI VGA > > > > > > Machine is fine, as it I can press Ctrl+Alt+Delete and reboot it > > > normally. > > > > > > 5.5 is OK. 5.6 is broken. > > > > I've heard some issues relating to missing firmware lately. It should > > work fine without firmware, but perhaps that got broken. Can you log > > into the machine and check dmesg to see what's there? My guess is that > > nouveau takes over from efifb, and then fails to load at some point in > > the middle. > > I've fixed the issue by including all firmware until "failed to load" > messages disappeared. X works and fbconsole on VT1-VT6 works too. > > CONFIG_EXTRA_FIRMWARE="nvidia/gp104/gr/sw_nonctx.bin > nvidia/gp104/gr/sw_ctx.bin nvidia/gp104/gr/sw_bundle_init.bin > nvidia/gp104/gr/sw_method_init.bin nvidia/gp104/gr/fecs_bl.bin > nvidia/gp104/gr/fecs_inst.bin nvidia/gp104/gr/fecs_data.bin > nvidia/gp104/gr/fecs_sig.bin nvidia/gp104/gr/gpccs_bl.bin > nvidia/gp104/gr/gpccs_inst.bin nvidia/gp104/gr/gpccs_data.bin > nvidia/gp104/gr/gpccs_sig.bin nvidia/gp104/sec2/image.bin > nvidia/gp104/sec2/desc.bin nvidia/gp104/sec2/sig.bin > nvidia/gp104/acr/ucode_load.bin nvidia/gp104/acr/ucode_unload.bin > nvidia/gp104/acr/bl.bin nvidia/gp104/acr/unload_bl.bin > nvidia/gp104/nvdec/scrubber.bin" Ben -- another report of firmware-less load being broken on v5.6. Alexey -- If you compile nouveau as a module, then these can live on your filesystem or initrd, depending on your boot process. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] gp104: regression on Linux 5.6
Hi Alexey, On Fri, Apr 24, 2020 at 10:52 PM Alexey Dobriyan wrote: > > gp104 refuses to switch to "graphic" mode and show anything past > this line: > > fb0: switching to nouveaufb from EFI VGA > > Machine is fine, as it I can press Ctrl+Alt+Delete and reboot it > normally. > > 5.5 is OK. 5.6 is broken. I've heard some issues relating to missing firmware lately. It should work fine without firmware, but perhaps that got broken. Can you log into the machine and check dmesg to see what's there? My guess is that nouveau takes over from efifb, and then fails to load at some point in the middle. > Bisecting is kinda painful with miscompilation and init/main.c breakage. > > BTW do I need all those megabytes of firmware? > > [0.923273] fb0: switching to nouveaufb from EFI VGA > [0.923440] nouveau :02:00.0: NVIDIA GP104 (134000a1) > [1.026681] nouveau :02:00.0: bios: version 86.04.1e.00.01 > [1.026930] nouveau :02:00.0: gr: failed to load firmware > "gr/sw_nonctx" > [1.026934] nouveau :02:00.0: gr: failed to load gr/sw_nonctx This is necessary to provide any sort of acceleration. Otherwise this is just a dumb scanout engine. You only need the firmware for your chipset, not all of it. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Error -28
Does it print anything else before that? There's definitely some dubious endian-unsafe code in the later nouveau stuff. For example, nvkm_falcon_v1_read_dmem seems to make assumptions about CPU being LE, based on a quick read of the code, and I would expect the file header parsing stuff does too. Cheers, -ilia On Sun, Apr 19, 2020 at 3:44 AM Christian Calderon wrote: > > I’m having trouble getting my GTX 1050 Ti working in Debian Sid. This machine > is a PowerMac G5, 2.3 GHz Dual Core. I’m using a Quadro FX 4500 as well and > it seems to work as expected. I’ve installed the firmware-linux-nonfree > package, which seems to have the required firmware for the GTX 1050 Ti. In > dmesg I see this error after some lines which mention “direct-loading > firmware”: > > nouveau 0001:06:00.0: gr ctor failed, -28 > > Any ideas on how to fix this? > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Status of GF108GLM [NVS 5200M]
On Fri, Apr 10, 2020 at 2:06 PM Jesús J. Guerrero Botella wrote: > > Hi, Ilia. > > Sorry for such a big delay in answering. Real life and that stuff... > > I am a newcomer so, please, if I do something wrong regarding my > quoting style or whatever, just let me know and I'll quickly improve. :) Perfect so far! > > El lun., 30 mar. 2020 a las 13:38, Ilia Mirkin > () escribió: > > > > Yes, GF108 is Fermi (F = Fermi). Reclocking is currently not available > > for that generation, unfortunately. You should be able to otherwise > > use your GPU just fine, but I'm guessing it'll come up in the "07" > > state when it powers on (in the state as-is it appears powered off, > > which it will do automatically when not in use), which as you can see > > is a fraction of the total GPU available perf. > > Yes, it comes up in 07 when I launch, let's say glxgears in DRI_PRIME=1. > It performs similarly to the intel chip, or maybe a bit worse. > For the rest, yes, it mostly works. But it's no good of course. Note that glxgears is primarily a measure of PCIe bandwidth in these setups than actual render performance (basically it's just ferrying those frames over the PCIe bus as fast as possible to the Intel GPU). Not sure which intel chip you have ... if it's a SNB, it should be faster and more featureful (you get GL 4.3 advertised and all the GL 4.5 and most 4.6 exts). If it's IVB or HSW, then it'll be a bit slower, I expect (esp HSW). > > There's a very experimental branch that does enable reclocking for > > Fermi at https://github.com/skeggsb/nouveau/commits/devel-clk . > > However I believe it was only tested with a single GPU, and my testing > > with an identical such GPU was negative. On the other hand, you don't > > have a display hanging off the card, which greatly increases chances > > of success. Feel free to join #nouveau on irc.freenode.net if you plan > > on exploring this. > > I fetched that and tried to compile it. First failed because of missing > envyas, > which I compiled and installed. Then failed with some undefined symbol kind > of error which right now I don't have the time to diagnose. I'm impressed you got this far. You shouldn't need envyas to build, by the way, only to regenerate after editing fuc source. So ... this is a funny repository. Basically it's meant to work alongside the linux kernel tree. It also includes some utilities (like the ones in bin/*) which essentially run nouveau in userspace. This can be useful for nouveau development, but most likely not in your case. What you want to do is grab kernel v4.16-rc5 (or v4.16 if you're feeling lucky), build + run that (or alternatively, ask Ben to rebase the branch on a more recent thing ... or even try that yourself). Then go into the "drm" directory and run "make" there. That should cause the nouveau module to get built against your kernel. Then use that built module for your testing (you could make modules_install from there, as I recall). Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] acr: failed to load firmware with Kernel 5.6. Kernel 5.5 works just fine.
On Fri, Apr 3, 2020 at 1:59 PM Zeno Davatz wrote: > > On Fri, Apr 3, 2020 at 7:23 PM Ilia Mirkin wrote: > > > > On Fri, Apr 3, 2020 at 1:21 PM Zeno Davatz wrote: > > > > > > On Fri, Apr 3, 2020 at 6:59 PM Ilia Mirkin wrote: > > > > > > > > Ben -- probably the ACR changes in 5.6 don't fall back nicely anymore > > > > when there's no firmware? The load shouldn't be failed, just GR > > > > disabled... > > > > > > > > Zeno -- if you grab linux-firmware, it should be all better. Not sure > > > > if you're missing it on purpose or by accident. > > > > > > Thank you, Ilia > > > > > > I will try that on my Gentoo/Funtoo machine now. So far linux-firmware > > > was not needed with Kernel 5.5, so it was not installed on my machine. > > > > It was needed on 5.5 as well. It's just that it fell back gracefully > > without firmware, and you didn't get any acceleration features. > > Do I need any of these enabled for linux-firmware to load properly in > Kernel 5.6? > > -*- Firmware loading facility > │ │ ()Build named firmware > blobs into the kernel binary > │ │ [ ] Enable the firmware > sysfs fallback mechanism > │ │ [ ] Enable compressed > firmware support Depends on distro specifics. Also the firmware has to be available at the time that nouveau loads. The corollary to this is: If it's built into the kernel, then the firmware must also be included in the kernel (since this happens before any FS stuff) If it's loaded as a module from initrd, then initrd must contain the firmware If you need help including firmware in the right place, a distro support channel is probably your best shot. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] acr: failed to load firmware with Kernel 5.6. Kernel 5.5 works just fine.
On Fri, Apr 3, 2020 at 1:21 PM Zeno Davatz wrote: > > On Fri, Apr 3, 2020 at 6:59 PM Ilia Mirkin wrote: > > > > Ben -- probably the ACR changes in 5.6 don't fall back nicely anymore > > when there's no firmware? The load shouldn't be failed, just GR > > disabled... > > > > Zeno -- if you grab linux-firmware, it should be all better. Not sure > > if you're missing it on purpose or by accident. > > Thank you, Ilia > > I will try that on my Gentoo/Funtoo machine now. So far linux-firmware > was not needed with Kernel 5.5, so it was not installed on my machine. It was needed on 5.5 as well. It's just that it fell back gracefully without firmware, and you didn't get any acceleration features. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] acr: failed to load firmware with Kernel 5.6. Kernel 5.5 works just fine.
Ben -- probably the ACR changes in 5.6 don't fall back nicely anymore when there's no firmware? The load shouldn't be failed, just GR disabled... Zeno -- if you grab linux-firmware, it should be all better. Not sure if you're missing it on purpose or by accident. Cheers, -ilia On Fri, Apr 3, 2020 at 11:07 AM Zeno Davatz wrote: > > Hi > > After installing Kernel 5.6 I am getting this error: > > [ please send a personal CC, thank you! ] > > Cannot run in framebuffer mode. Please specify busIDs for all > framebuffer devices > > [ 0.757317] nouveau :05:00.0: NVIDIA GP107 (137000a1) > [ 0.869775] nouveau :05:00.0: bios: version 86.07.42.00.4a > [ 0.870157] nouveau :05:00.0: acr: failed to load firmware > [ 0.870256] nouveau :05:00.0: acr: failed to load firmware > [ 0.870356] nouveau :05:00.0: acr ctor failed, -2 > [ 0.870455] nouveau: probe of :05:00.0 failed with error -2 > > This used to work just fine, with Version 5.5, Gentoo/Funtoo Linux. > > Very strange. > > With Kernel 5.5 everything was fine: > > this is what I get with Kernel 5.5 > > ~/.backup> dmesg | grep nouveau > [ 0.994622] nouveau :05:00.0: NVIDIA GP107 (137000a1) > [ 1.107079] nouveau :05:00.0: bios: version 86.07.42.00.4a > [ 1.107391] nouveau :05:00.0: gr: failed to load firmware "gr/sw_nonctx" > [ 1.107494] nouveau :05:00.0: gr: failed to load gr/sw_nonctx > [ 1.107857] nouveau :05:00.0: fb: 4096 MiB GDDR5 > [ 1.124158] nouveau :05:00.0: DRM: VRAM: 4096 MiB > [ 1.124268] nouveau :05:00.0: DRM: GART: 536870912 MiB > [ 1.124381] nouveau :05:00.0: DRM: BIT table 'A' not found > [ 1.124493] nouveau :05:00.0: DRM: BIT table 'L' not found > [ 1.124604] nouveau :05:00.0: DRM: TMDS table version 2.0 > [ 1.124719] nouveau :05:00.0: DRM: DCB version 4.1 > [ 1.124829] nouveau :05:00.0: DRM: DCB outp 00: 01000f42 04620030 > [ 1.124941] nouveau :05:00.0: DRM: DCB outp 01: 02011f62 00020010 > [ 1.125054] nouveau :05:00.0: DRM: DCB outp 02: 02822f76 04600020 > [ 1.125166] nouveau :05:00.0: DRM: DCB outp 03: 02022f72 00020020 > [ 1.125278] nouveau :05:00.0: DRM: DCB outp 04: 04033f82 00020030 > [ 1.125390] nouveau :05:00.0: DRM: DCB conn 00: 1031 > [ 1.125501] nouveau :05:00.0: DRM: DCB conn 01: 00010161 > [ 1.125612] nouveau :05:00.0: DRM: DCB conn 02: 00020246 > [ 1.125723] nouveau :05:00.0: DRM: DCB conn 03: 01000331 > [ 1.126100] nouveau :05:00.0: DRM: failed to create kernel channel, -22 > [ 1.126364] nouveau :05:00.0: DRM: MM: using COPY for buffer copies > [ 1.481589] nouveau :05:00.0: DRM: allocated 1680x1050 fb: > 0x20, bo (ptrval) > [ 1.481807] fbcon: nouveaudrmfb (fb0) is primary device > [ 1.672191] nouveau :05:00.0: fb0: nouveaudrmfb frame buffer device > [ 1.672362] [drm] Initialized nouveau 1.3.1 20120801 for :05:00.0 on > minor 1 > > Kernel Config is attached. > > Looking forward to any help or reply. > > I went back to version 5.5 of the Kernel (recompiled after git > checkout v5.5) and all is fine again. > > Best > Zeno ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Display broken after resume from suspend
Sorry, haven't really looked since our initial interaction. That EDID decodes as: Block 0, Base EDID: EDID Structure Version & Revision: 1.0 Vendor & Product Identification: Manufacturer: SEC Model: 21569 Made in: 2010 Basic Display Parameters & Features: Digital display Maximum image size: 34 cm x 19 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Color Characteristics: Red : 0.6201, 0.3398 Green: 0.3300, 0.5703 Blue : 0.1503, 0.0595 White: 0.3134, 0.3291 Established Timings I & II: none Standard Timings: none Detailed Timing Descriptors: DTD 1: 1366x76860.003 Hz 683:384 47.402 kHz 75.180 MHz (344 mm x 194 mm) Hfront 48 Hsync 32 Hback 140 Hpol P Vfront2 Vsync 5 Vback 15 Vpol N DTD 2: 1366x76839.999 Hz 683:384 31.599 kHz 48.220 MHz (344 mm x 194 mm) Hfront 48 Hsync 32 Hback 80 Hpol P Vfront2 Vsync 5 Vback 15 Vpol N Alphanumeric Data String: 'T892T' Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 41 01 19 00 00 00 00 09 01 0a 20 20 'A. ' Checksum: 0x4 edid-decode SHA: 9bdf55523f83072f5c056953f1fbc9fcf09d9496 Warnings: Block 0, Base EDID: EDID Structure Version & Revision: EDID 1.0 is deprecated, do not use. Failures: Block 0, Base EDID: Basic Display Parameters & Features: Digital Video Interface Standard set to reserved value 0x15. Display Descriptor #3: Has descriptor blocks other than detailed timings. Alphanumeric Data String: Non-printable character. Display Descriptor #4: Has descriptor blocks other than detailed timings. and in your logs you have [ 289.906506] nouveau :01:00.0: disp: outp 00:0006:0344: data 281925 KB/s link 0 KB/s mst 0->0 [ 289.906511] nouveau :01:00.0: disp: outp 00:0006:0344: link requirements changed Where completely coincidentally, 75180 * 30 / 8 = 281925 So it's clearly wanting 10bpc. And based on my reading of the logic in drm_edid.c, your display_info.bpc with that edid would == 0. However in nouveau_connector_detect_depth() we would then force it to 6. And in nv50_mstc_get_modes it'd become 8. So this is still a bit unclear to me. If you're up to it, do some tracing, try to figure out why it's deciding to do 10bpc. Cheers, -ilia On Tue, Mar 31, 2020 at 8:37 PM Joshua J. Kugler wrote: > > Just curious if any of the recent fixes have addressed this. :) > > j > > On Tuesday, January 14, 2020 1:05:28 PM AKDT Joshua J. Kugler wrote: > > Another log, per Lyude on #nouveau. > > > > j > > > > On Tuesday, January 14, 2020 8:52:51 AM AKST Joshua J. Kugler wrote: > > > Here we go! > > > > > > j > > > > > > On Tuesday, January 14, 2020 7:08:20 AM AKST Ilia Mirkin wrote: > > > > Hi Joshua, > > > > > > > > Not a fix for your issue, but Ben noticed this (and fixed it): > > > > > > > > https://github.com/skeggsb/nouveau/commit/024bda7d2b0c3b0731433d60a494c7 > > > > 8a > > > > b5 8cb216 > > > > > > > > which is what causes us to even try 540MB/s link training. However > > > > with this fix applied, it'll just give up faster. I'm told eDP is > > > > generally a single lane, and you're trying to get more than 270MB/s. > > > > So ... the question is ... why is it trying to do 10bpc. One likely > > > > reason is that the display_info.bpc == 0 for some reason (and we, > > > > rather questionably, default to 10bpc for bandwidth determination). > > > > There's no concrete theory as to what that reason might be, but it > > > > would explain what's going on. > > > > > > > > After resuming into a bad state, can you grab the contents of > > > > /sys/class/drm/card0-eDP-1/edid (you'll have to cat it or something)? > > > > My hope is that it's somehow messed up. > > > > > > > > Also, can you add "drm.debug=0x1e" to the boot cmd line, in addition > > > > to the bits you have already? Should provide some more info, perhaps > > > > some of it will even be relevant. > > > > > > > > Thanks, > > > > > > > > -ilia > > > > > > > > On Mon, Jan 13, 2020 at 6:48 PM Joshua J. Kugler > > > > wrote: > > > > > I've added debugging command-line parameters to the kernel command > > > > > line, > > > > > per skeggsb and imirkin on #nouveau. > > > > > > > > > > root@joyful:~# ca
Re: [Nouveau] Status of GF108GLM [NVS 5200M]
Yes, GF108 is Fermi (F = Fermi). Reclocking is currently not available for that generation, unfortunately. You should be able to otherwise use your GPU just fine, but I'm guessing it'll come up in the "07" state when it powers on (in the state as-is it appears powered off, which it will do automatically when not in use), which as you can see is a fraction of the total GPU available perf. For example `DRI_PRIME=1 glxinfo` should show you that it's using nouveau. There's a very experimental branch that does enable reclocking for Fermi at https://github.com/skeggsb/nouveau/commits/devel-clk . However I believe it was only tested with a single GPU, and my testing with an identical such GPU was negative. On the other hand, you don't have a display hanging off the card, which greatly increases chances of success. Feel free to join #nouveau on irc.freenode.net if you plan on exploring this. Cheers, -ilia On Mon, Mar 30, 2020 at 3:22 AM Jesús J. Guerrero Botella wrote: > > Hello. > > I am not subscribed to the list, so, please, if I do anything wrong > just let me know politely and I'll try to improve :) > > I just want to know if there's any branch of nouveau version that will > work with this chip. lspci lists it as: > > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS > 5200M] (rev a1) > > I think it's Fermi, but I am not sure. When I try to change pstate it says: > > # LC_ALL=C echo '0f' > /sys/kernel/debug/dri/1/pstate > bash: echo: write error: Function not implemented > # LC_ALL=C cat /sys/kernel/debug/dri/1/pstate > 03: core 50 MHz memory 135 MHz > 07: core 202 MHz memory 324 MHz > 0f: core 672 MHz memory 1569 MHz > AC: core 0 MHz memory 0 MHz > > It's worth noting that's a secondary gpu. I just use the intel chip > for everyday's work, but I have some free days and I am trying to get > the secondary one working and put it to good use, if possible. > > Thanks for any help you can provide. Please, CC me, as said, I am not > subscribed to the list even though I'll try to keep an eye on this. > > > -- > Jesús Guerrero Botella > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Question on MME and Compute Subchannel in Kepler+
I believe that there's a single shared resource for MME in GRAPH, not separate ones for separate classes. Ultimately, the classes just provide frontends for the single internal GRAPH engine. (This is probably also why setting some stuff on the compute class "unsets" it on the 3d class, or sometimes is directly visible.) For compute on Kepler+, you don't actually need to use macros for indirect compute dispatch -- the launch descriptor which contains the grid dimensions is in memory, and the technique used is to just use UPLOAD_EXEC to overwrite the necessary bits. (Small aside - Pascal got a new launch descriptor, I forget which gen switch is.) Check how nouveau does it in nve4_compute_upload_input (look for the info->indirect case). But you can see an example of a compute macro for Fermi (where there is no separate launch descriptor): https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/mme/com90c0.mme And it's installed the same way as all the "3d" macros are: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c#n1429 As an aside, you may find this MME emulator useful in demmt. It's fully accurate, AFAIK: https://github.com/envytools/envytools/blob/master/demmt/macro.c Hope this helps! -ilia On Fri, Mar 27, 2020 at 9:34 PM Fernando Sahmkow wrote: > > Hello everyone, > > I've been trying to adapt a switch emulator to emulate nouveau's compute. > We've been told some things like indirect dispatch use the MME in Nouveau, > however, looking at NVIDIA's open gpu documentation there's no MME in compute > engine since Kepler. > https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/compute/clb1c0.h > MME for compute should still exist because of the presence of MME Shadow > Memory Scratch registers. > > How does MME for Compute works on Kepler+ ? Does it use the 3D Subchannel? if > so how do I know when its targeting the Compute Subchannel? > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] DP MST with GK107 and lenovo ultra dock
Hi Jasmin,
On Sun, Mar 1, 2020 at 11:32 AM Jasmin wrote:
>
> Hi,
>
> for quite some time now I would like to switch from the proprietary driver to
> nouveau, using a GK107 (Quadro) in a thinkpad.
> Unfortunately the monitors connected to the lenovo "ultra dock" are not
> properly recognized when using nouveau.
DP-MST support was first added to nouveau for precisely these kinds of
setups. It does, generally, work, so that means there's something
extra-special about your setup.
>
> The laptop contains a multiplexer: so in the bios it can be selected, whether
> the docking station's DP/HDMI/VGA-Ports are "directly" connected to the
> dedicated GK701 or to the integrated intel GPU.
> I have selected the GK107, which is used as primary GPU (by the xserver): I
> use reverse prime to also display something on the laptop-screen, which stays
> connected to the intel-gpu.
> This setup with all 4 screens works with the proprietary driver (but many
> other things are not properly working with it), but with noveau only 2
> monitors are recognized: the reverse-prime-screen(intel), and "one other"
> monitor.
> As far as I know the ultra dock uses DP MST for making it possible to
> simultaneously connect/drive 3 individual monitors: so for me it looks like
> DP MST is not working in this case, because only "one" monitor is found.
>
> After looking into the source code I guess, the connectors are not properly
> recognized – perhaps because the dock's DP-uplink port is not recognized as
> MST-capable ("connector type" DP is needed here?), because some kernel log
> lines are not shown, that I would expect to show, if the code was going
> through its MST sections. Or it has something to do with the I2C-bus, that
> seems to be used by some docks (AUX I2C)? Nothing is found on the i2c-busses
> provided by nouveau.
> The connector information seems to be read from a "DCB", and there are no
> I2C-Bits set... however: I am not into this topic, so I can only guess
> without further experiments.
>
> Below there is the kernel log with some debugging enabled (especially the
> last line and DCB lines are possibly relevant)...
> Thanks for any help.
>
> Jasmin
>
>
> Feb 28 23:07:10 laptop kernel: [0.172771] Kernel command line:
> BOOT_IMAGE=/vmlinuz-5.4.0-0.bpo.3-amd64 root=/dev/mapper/systemvg-systemlv ro
> nouveau.config=NvI2C=1 nouveau.debug=I2C=debug,DRM=debug nouveau.mst=1
I'm not sure what NvI2C does anymore, but you probably don't want it.
Also nouveau.mst isn't a think anymore (it might have been for a few
releases while we weren't sure about it working).
> Feb 28 23:07:10 laptop kernel: [ 13.277531] nouveau: detected PR support,
> will not use DSM
> Feb 28 23:07:10 laptop kernel: [ 13.277572] nouveau :01:00.0: enabling
> device ( -> 0003)
> Feb 28 23:07:10 laptop kernel: [ 13.278585] nouveau :01:00.0: NVIDIA
> GK107 (0e7360a2)
> Feb 28 23:07:10 laptop kernel: [ 13.390704] nouveau :01:00.0: bios:
> version 80.07.ac.00.20
> Feb 28 23:07:10 laptop kernel: [ 13.390713] nouveau :01:00.0: i2c: ccb
> 00: type 05 drive 00 sense ff share ff auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.390825] nouveau :01:00.0: i2c: ccb
> 01: type 05 drive 01 sense ff share ff auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.390877] nouveau :01:00.0: i2c: ccb
> 02: type 05 drive 02 sense ff share ff auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.390924] nouveau :01:00.0: i2c: ccb
> 03: type ff drive ff sense ff share ff auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.390926] nouveau :01:00.0: i2c: ccb
> 04: type ff drive ff sense ff share ff auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.390927] nouveau :01:00.0: i2c: ccb
> 05: type 05 drive 05 sense ff share ff auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.390971] nouveau :01:00.0: i2c: ccb
> 06: type 05 drive 06 sense ff share 00 auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.391014] nouveau :01:00.0: i2c: ccb
> 07: type 05 drive 07 sense ff share 01 auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.391058] nouveau :01:00.0: i2c: ccb
> 08: type 05 drive 08 sense ff share 02 auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.391101] nouveau :01:00.0: i2c: ccb
> 09: type 05 drive 09 sense ff share 03 auxch ff
> Feb 28 23:07:10 laptop kernel: [ 13.391145] nouveau :01:00.0: i2c: ccb
> 0a: type 06 drive ff sense ff share 00 auxch 00
> Feb 28 23:07:10 laptop kernel: [ 13.391187] nouveau :01:00.0: i2c: ccb
> 0b: type 06 drive ff sense ff share 01 auxch 01
> Feb 28 23:07:10 laptop kernel: [ 13.391230] nouveau :01:00.0: i2c: ccb
> 0c: type 06 drive ff sense ff share 02 auxch 02
> Feb 28 23:07:10 laptop kernel: [ 13.391273] nouveau :01:00.0: i2c: ccb
> 0d: type 06 drive ff sense ff share 03 auxch 03
> Feb 28 23:07:10 laptop kernel: [ 13.391318] nouveau :01:00.0: i2c: ccb
> 0e: type ff drive ff sense ff share ff auxch ff
> Feb 28 23:07:11 laptop kernel: [
Re: [Nouveau] Problems with nouveau driver in Ubuntu 18.04
Can you try to figure out what was updated in the latest updates? My guess would be that it's actually the software used to display your desktop/etc which changed. You can disable all accel by booting with nouveau.noaccel=1. Cheers, -ilia On Sat, Feb 29, 2020 at 12:31 AM Juan Manuel Alvarez wrote: > > Hello, > > > I use Ubuntu 18.04, since one of the last upgrades I have problems with > nouveau drivers. > > My screen look like the picture atteched. > > > [~]$ uname -a > Linux 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 > x86_64 x86_64 x86_64 GNU/Linux > > [~]$ inxi -Gx > Graphics: Card: NVIDIA G71GL [Quadro FX 1500] bus-ID: 01:00.0 >Display Server: x11 (X.Org 1.20.5 ) driver: nouveau Resolution: > 1920x1080@60.00hz, 1920x1080@60.00hz >OpenGL: renderer: NV49 version: 2.1 Mesa 19.2.8 Direct Render: Yes > > I have tried to install Nvidia driver 304.137, but it seems is not supported > in Ubuntu 18.04 anymore. > > > Are there any nouveau upgrade (that it is not on Canonical) that fixes this > problem? > > Or how I can downgrade nouveau driver to any previous one that works fine in > ubuntu 18.04 with my graphics card? > > > Regards! > > Juanma > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] where to report modesetting DDX bug?
On Fri, Feb 28, 2020 at 11:06 AM Felix Miata wrote: > Video and input drivers Subgroups and projects on gitlab does not list > modesetting > DDX, presumably because it's not packaged separately from the server. Where's > the > right place to report a modesetting DDX bug that manifests only on an NVidia > GPU? > Directly against the server https://gitlab.freedesktop.org/xorg/xserver? I don't know if anyone (from nouveau) looks at gitlab, so mailing list is probably best anyways. > > Here are some particulars: > How can I tell whether this should be reported to kernel tracker or to > freedesktop > tracker as driver or server problem? HDMI output on GT218 10de:0a65 GPU is > limited > to 1920x1200. When connected to 2560x1440 display, vttys are supported at > display's supported 1920x1080 mode, but X with modesetting DDX puts display in > unsupported mode (functionally asleep) regardless of various attempts to force > 1920x1080@60 or 1600x900@60, while with nouveau DDX, or 1920x1200 display, or > 2560x1440 display with Dual-link DVI cable, display behavior is as expected. > > openSUSE 15.1/kernel 4.12.14OK > openSUSE 15.2/kernel 5.3.18 bad > Tumbleweed/kernel 5.4.14bad > Debian Buster/kernel 4.19.x OK > Fedora 31/5.5.5 kernel bad > > http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-gt218-stw-modesetting-OOR-0x1e > http://fm.no-ip.com/Tmp/Linux/Xorg/gt218-dmesg-stw.txt Those HDMI mode clocks are too high against the nominal single-link 165MHz TMDS. You can set your own maximum with nouveau.hdmimhz=300 (for example) to allow it. I believe the connectors aren't rated for that though. The commit which fixed this is commit d1084184789d677df4e9c110f38cb3f3d709195d Author: Ben Skeggs Date: Wed May 29 09:58:18 2019 +1000 drm/nouveau/kms: disallow dual-link harder if hdmi connection detected and went into v5.3. I'm not sure where this got broken... I think it would have been commit 9340d77f5327ea673a7f95f58139123d7a278243 Author: Ilia Mirkin Date: Mon Sep 3 20:57:37 2018 -0400 drm/nouveau/disp: take sink support into account for exposing 594mhz which went into v4.20, but it could also have been commit 1a0c96c075bb4517d4ce4fb6750ee0a3cf38714c Author: Ilia Mirkin Date: Tue Nov 3 21:00:11 2015 -0500 drm/nouveau/kms: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler which went into v4.5 and lines up with your timeline better, but seems like it shouldn't be handing out those high frequencies to HDMI connectors on tesla... Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] drm: Add separate state structure for legacy, non-KMS drivers
On Tue, Feb 25, 2020 at 10:59 AM Thomas Zimmermann wrote:
>
> Non-KMS drivers store state in struct drm_driver. This bloats the
> structure for KMS drivers and prevents it from being declared with
> 'static const' qualifiers. Moving the non-KMS state into a separate
> data structure resolves this.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_drv.c | 4
> drivers/gpu/drm/i810/i810_drv.c | 4
> drivers/gpu/drm/mga/mga_drv.c | 4
> drivers/gpu/drm/nouveau/nouveau_drm.c | 8
> drivers/gpu/drm/r128/r128_drv.c | 4
> drivers/gpu/drm/savage/savage_drv.c | 4
> drivers/gpu/drm/sis/sis_drv.c | 4
> drivers/gpu/drm/tdfx/tdfx_drv.c | 4
> drivers/gpu/drm/via/via_drv.c | 4
> include/drm/drm_drv.h | 3 +++
> include/drm/drm_legacy.h | 6 ++
> 11 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7b1a628d1f6e..4ba0df097602 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -625,6 +625,10 @@ int drm_dev_init(struct drm_device *dev,
> if (WARN_ON(!parent))
> return -EINVAL;
>
> + if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> + WARN_ON(!driver->legacy))
> + return -EINVAL;
> +
> kref_init(&dev->ref);
> dev->dev = get_device(parent);
> dev->driver = driver;
> diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
> index 0e53a066d4db..55f17f00bae9 100644
> --- a/drivers/gpu/drm/i810/i810_drv.c
> +++ b/drivers/gpu/drm/i810/i810_drv.c
> @@ -56,6 +56,9 @@ static const struct file_operations i810_driver_fops = {
> .llseek = noop_llseek,
> };
>
> +static struct drm_legacy_state = i810_legacy_state {
Does this compile? I might have assumed this would need to be
static struct drm_legacy_state i810_legacy_state = {
> +};
> +
> static struct drm_driver driver = {
> .driver_features = DRIVER_USE_AGP | DRIVER_HAVE_DMA | DRIVER_LEGACY,
> .dev_priv_size = sizeof(drm_i810_buf_priv_t),
> @@ -71,6 +74,7 @@ static struct drm_driver driver = {
> .major = DRIVER_MAJOR,
> .minor = DRIVER_MINOR,
> .patchlevel = DRIVER_PATCHLEVEL,
> + .legacy = &i810_legacy_state,
> };
>
> static struct pci_driver i810_pci_driver = {
> diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.c
> index 71128e6f6ae9..4865982d949c 100644
> --- a/drivers/gpu/drm/mga/mga_drv.c
> +++ b/drivers/gpu/drm/mga/mga_drv.c
> @@ -53,6 +53,9 @@ static const struct file_operations mga_driver_fops = {
> .llseek = noop_llseek,
> };
>
> +static struct drm_legacy_state = mga_legacy_state {
> +};
> +
> static struct drm_driver driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_LEGACY |
> @@ -78,6 +81,7 @@ static struct drm_driver driver = {
> .major = DRIVER_MAJOR,
> .minor = DRIVER_MINOR,
> .patchlevel = DRIVER_PATCHLEVEL,
> + .legacy = &mga_legacy_state,
> };
>
> static struct pci_driver mga_pci_driver = {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 6b1629c14dd7..c88cf32e521c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -1103,6 +1103,11 @@ nouveau_driver_fops = {
> .llseek = noop_llseek,
> };
>
> +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
> +static struct drm_legacy_state nouveau_legacy_state{
> +};
> +#endif
> +
> static struct drm_driver
> driver_stub = {
> .driver_features =
> @@ -1150,6 +1155,9 @@ driver_stub = {
> .major = DRIVER_MAJOR,
> .minor = DRIVER_MINOR,
> .patchlevel = DRIVER_PATCHLEVEL,
> +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
> + .legacy = &nouveau_legacy_state,
> +#endif
> };
>
> static struct pci_device_id
> diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
> index b7a5f162ebae..ecece3a48d93 100644
> --- a/drivers/gpu/drm/r128/r128_drv.c
> +++ b/drivers/gpu/drm/r128/r128_drv.c
> @@ -57,6 +57,9 @@ static const struct file_operations r128_driver_fops = {
> .llseek = noop_llseek,
> };
>
> +static struct drm_legacy_state = r128_legacy_state {
> +};
> +
> static struct drm_driver driver = {
> .driver_features =
> DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_SG | DRIVER_LEGACY |
> @@ -81,6 +84,7 @@ static struct drm_driver driver = {
> .major = DRIVER_MAJOR,
> .minor = DRIVER_MINOR,
> .patchlevel = DRIVER_PATCHLEVEL,
> + .legacy = &r128_legacy_state,
> };
>
> int r128_driver_load(struct drm_device *dev, unsigned long flags)
> diff --git a/drivers/gpu/drm/savage/savage_drv.c
> b/drivers/gpu/drm/savage/savage_drv.c
> index 799bd11adb9c..c0a7146fbde1 100644
> --- a/drivers/gpu/drm/savage/savage_
Re: [Nouveau] NV40 under Debian
On Sat, Feb 22, 2020 at 1:02 PM Lukas Schubert wrote: > > Hi list, > > my media center PC is freshly installed with Debian 10.2 "Buster". It doesn't > support Geforce 6800 GT (NV40) boards through the nvidia nor the > nvidia-legacy drivers any longer. The legacy drivers worked up until Debian 9 > "Stretch", but no longer. > > I know that the hardware works because I can boot SystemRescueCD from CD and > get a flawless desktop presentation on the attached full HD TV. > > But in Debian 10, the colours are distorted. Have a look at "Nouveau.jpg" > here: https://jumpshare.com/b/Se5d7xMu5tBSsR2Zcz8p > I can get the colours to work by starting the kernel with "nomodeset". Look > at the same link, "NoModeSet.jpg". > > SystemRescueCD (working nouveau version) uses an older kernel: > root@sysresccd /root % uname -a > Linux sysresccd 3.2.28-std300-amd64 #2 SMP Tue Aug 21 18:35:38 UTC 2012 > x86_64 Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz GenuineIntel GNU/Linux > > Debian 10.2 (distorted colours) uses this kernel: > luker@michael:~$ uname -a > Linux michael 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 > GNU/Linux > > Is there a configuration setting in nouveau that causes those weird colours? > Bit order/byte order maybe? As you might suspect, there have been a few changes here and there between v3.2, released in 2012, and v4.19, released in 2018. Could you perhaps try a couple of Ubuntu (or pick-your-favorite-distro) LiveUSB releases to see if you can narrow it down at all? You don't have to install them, just booting them should reveal the issues, most likely. This looks like either a messed up LUT, or a disagreement in color layout in the framebuffer, e.g. RGB565 vs XRGB1555. The underlying picture still has the correct shape, so it's not a 4- vs 2-byte confusion. XRGB vs XBGR would look differently wrong, so it's not the byte order (which the scanout engine does support flipping, but we don't expose that in nouveau right now). Does the vt console look OK? i.e. light-gray text on black background? If you have colors in your shell, do they seem OK too? Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
Hi Frédéric,
It appears Ben made his own version of this patch (probably based on
the one you added to the kernel bz), and it's already upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2
Cheers,
-ilia
On Thu, Feb 20, 2020 at 12:19 PM Frédéric Pierret
wrote:
>
> Hi,
> Is anything missing here? How can I get this merged?
>
> Best regards,
> Frédéric Pierret
>
> On 2020-02-08 20:43, Frédéric Pierret wrote:
> > Pointer to structure array is assumed not NULL by default. It has
> > the consequence to raise a kernel panic when it's not the case.
> >
> > Basically, running at least a RTX2080TI on Xen makes a bad mmio error
> > which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the
> > code, it's assumed to be not NULL by accessing directly 'mthd->data[0]'
> > which is the reason of the kernel panic. Simply check if the pointer
> > is not NULL before continuing.
> >
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206299
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Frédéric Pierret (fepitre)
> > ---
> > drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> > b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> > index bcf32d92ee5a..50e3539f33d2 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> > @@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int
> > debug)
> >
> > if (debug > subdev->debug)
> > return;
> > + if (!mthd)
> > + return;
> >
> > for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
> > u32 base = chan->head * mthd->addr;
> >
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
So ... for Vulkan, the API requires allocating VA before declaring
what goes into that VA (e.g. an image or data). I believe our plan for
that was to move all this into userspace, which would allocate VA and
then just tell the kernel "make VA range X have memtype Y". At that
point, nouveau_bo would be left mainly for compat as well as for
things like framebuffer backing.
James, in what situation would the modifier be different than the bo's memtype?
-ilia
On Thu, Feb 6, 2020 at 10:43 AM James Jones wrote:
>
> The format modifiers, when present, override the equivalent field in the
> BO. Right now, that's probably not particularly useful. However, as
> nouveau interfaces evolve towards the HW capabilities and add support
> for newer graphics APIs, saying an entire BO has a singular layout
> becomes less meaningful, so I suspect those fields will be effectively
> deprecated in favor of the modifier-defined and, for non-FB operations,
> strictly userspace defined layout. Doing so will be much easier if the
> modifier support is already in place for applications to start making
> use of.
>
> Thanks,
> -James
>
> On 2/6/20 7:28 AM, Roy Spliet wrote:
> > (Re-sending to list rather than just to James)
> >
> > Is this format modifier information not stored, or otherwise worth
> > storing, directly in the nouveau_bo object associated with the
> > framebuffer? I'm not particularly knowledgeable on the topic, but there
> > already seem to exist some fields with very similar names in nouveau_bo.
> > Best,
> >
> > Roy
> >
> > On 06/02/2020 15:17, James Jones wrote:
> >> Note I'm adding some fields to nouveau_framebuffer in the series
> >> "drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that
> >> yesterday. It would probably still be possible to avoid them by
> >> re-extracting the relevant data from the format modifier on the fly
> >> when needed, but it is simpler and likely less error-prone with the
> >> wrapper struct.
> >>
> >> Thanks,
> >> -James
> >>
> >> On 2/6/20 2:19 AM, Thomas Zimmermann wrote:
> >>> After its cleanup, struct nouveau_framebuffer is only a wrapper around
> >>> struct drm_framebuffer. Use the latter directly.
> >>>
> >>> Signed-off-by: Thomas Zimmermann
> >>> ---
> >>> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++
> >>> drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++--
> >>> drivers/gpu/drm/nouveau/nouveau_display.h | 12 +--
> >>> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 14 ++--
> >>> 4 files changed, 28 insertions(+), 38 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> >>> b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> >>> index ba1399965a1c..4a67a656e007 100644
> >>> --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> >>> +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> >>> @@ -40,11 +40,11 @@ nv50_wndw_ctxdma_del(struct nv50_wndw_ctxdma
> >>> *ctxdma)
> >>> }
> >>> static struct nv50_wndw_ctxdma *
> >>> -nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct
> >>> nouveau_framebuffer *fb)
> >>> +nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct drm_framebuffer
> >>> *fb)
> >>> {
> >>> -struct nouveau_drm *drm = nouveau_drm(fb->base.dev);
> >>> +struct nouveau_drm *drm = nouveau_drm(fb->dev);
> >>> struct nv50_wndw_ctxdma *ctxdma;
> >>> -struct nouveau_bo *nvbo = nouveau_gem_object(fb->base.obj[0]);
> >>> +struct nouveau_bo *nvbo = nouveau_gem_object(fb->obj[0]);
> >>> const u8kind = nvbo->kind;
> >>> const u32 handle = 0xfb00 | kind;
> >>> struct {
> >>> @@ -236,16 +236,16 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw
> >>> *wndw, bool modeset,
> >>> struct nv50_wndw_atom *asyw,
> >>> struct nv50_head_atom *asyh)
> >>> {
> >>> -struct nouveau_framebuffer *fb =
> >>> nouveau_framebuffer(asyw->state.fb);
> >>> +struct drm_framebuffer *fb = asyw->state.fb;
> >>> struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
> >>> -struct nouveau_bo *nvbo = nouveau_gem_object(fb->base.obj[0]);
> >>> +struct nouveau_bo *nvbo = nouveau_gem_object(fb->obj[0]);
> >>> int ret;
> >>> NV_ATOMIC(drm, "%s acquire\n", wndw->plane.name);
> >>> -if (asyw->state.fb != armw->state.fb || !armw->visible ||
> >>> modeset) {
> >>> -asyw->image.w = fb->base.width;
> >>> -asyw->image.h = fb->base.height;
> >>> +if (fb != armw->state.fb || !armw->visible || modeset) {
> >>> +asyw->image.w = fb->width;
> >>> +asyw->image.h = fb->height;
> >>> asyw->image.kind = nvbo->kind;
> >>> ret = nv50_wndw_atomic_check_acquire_rgb(asyw);
> >>> @@ -261,13 +261,13 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw
> >>> *wndw, bool modeset,
> >>> asyw->image.blockh = nvbo->mode >> 4;
> >>> else
> >>> asyw->image.blockh = nvbo->mode;
> >>> -asyw->image.blocks[0] = fb->bas
Re: [Nouveau] Firmware required?
All GPUs supported by nouveau (Riva TNT and newer) can work without additional firmware. It all depends on the definition of what one means by "work", of course. Across the board, modesetting works without any additional firmware (i.e. lighting up displays, making pictures appear on them), including DP-MST. There is no support for HDR yet, but it's something I've dabbled with a bit. (No firmware required.) NV17/18 boards (GeForce 2/4 MX) have support for MPEG1/MPEG2 decoding acceleration, but there is no support for this in nouveau (no firmware required, just ... motivation). NV4x/G7x (and the G80, I think) boards have a VP1 video decoding engine which helps with some sort of WMV accel, which would require firmware to operate. However there is no support for this in nouveau, no linux drivers shipped by NVIDIA ever supported this, and by all accounts, it didn't actually make things faster on Windows. Starting with the G84 (and nouveau support ending at the GK20x series), you need additional firmware for video decoding acceleration. There is a script to extract this firmware from shipped NVIDIA drivers, although the results can't be redistributed. This is detailed at https://nouveau.freedesktop.org/wiki/VideoAcceleration/ . There are some bugs in the H264 decoding which have never been tracked down, but for most videos, it works fine. A handful of GK106 boards (marketed as GTX 660) benefit from NVIDIA-supplied context switching firmware. We have no idea why - the nouveau-supplied one should be fine, but probably some error condition is mishandled. Or something else odd. Kepler and newer boards support video encoding, which requires firmware, but nouveau has no support for this. Starting with GM20x (generally, marketing names like GTX 9xx, but not always), you need additional firmware for any 2D/3D acceleration, as cryptographic signatures are verified by the GPU. While NVIDIA supplies the firmware needed for acceleration (generally with a 1-2 year delay after launch), they do not supply the firmware necessary for the PMU, which would control things like fans, voltages, clock frequencies. Since (modern) GPUs boot up in the lowest performance levels, that means that you're stuck there with nouveau, getting 5-10% of maximum performance, depending on specifics. There is presently no 3D acceleration support in mesa for Volta or Turing, although I'm told this is in the works. There is also no 2D acceleration support for Volta or Turing in xf86-video-nouveau. Volta's shader execution model has changed somewhat from earlier gens (while Fermi/Kepler/Maxwell were largely identical), so this has required some additional effort (and since there's no ability to have reclocking on those boards, a profound lack of caring from me). I expect there are bits I missed here ... not 100% sure whether s2ram would work on GM20x+ without firmware. Hope this helps, -ilia On Sun, Feb 2, 2020 at 6:09 AM Dennis den Brok wrote: > > Dear nouveau@, > > please forgive me if this is a FAQ or otherwise obvious; it isn't to me > from searching the web, the nouveau mailing list archives and various > Linux distributions' wiki pages. > > I'd like to know for which nvidia GPUs a firmware binary blob needs to > be loaded to the GPU in order for nouveau to work with it, including > binaries from what is often called "linux-firmware". Hopefully more > precisely: > > Are there GPUs supported by nouveau which do not work at all without a > binary blob? > > Are there GPUs which work partially without a firmware binary blob? > What are the restrictions? > > Are there GPUs which work without restrictions? > > If there is a resource with answers to my questions, I'd be grateful > for a reference. > > Please CC me, as I am not subscribed to the list. > > Thanks and regards, > > Dennis den Brok > > > > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] G84 with kernel 5.3 hanging issues
OK, so if you're sure it's the kernel, the way forward would be to do a git bisect to find the offending commit. Cheers, -ilia On Thu, Jan 30, 2020 at 4:33 PM Dave wrote: > Thanks for replying, below are the only items I installed when I had the > problem last time > > > The sequence of events were: > > I took an LVM snap > > I initially installed all the pending packages and had the issue > > I reverted back to before the lvm snap, made sure I didn't have the issue > > I installed everything but the kernel, made sure I didn't have the issue > and removed the snap > > Then installed the kernel (see below) and had the issue again > > I also tried running specific applications individually to see if it was > related to only a certain app but, that was not the case > > > Thanks > > Dave > > > > On 1/30/20 11:02 AM, Ilia Mirkin wrote: > > This is not a known issue. No GPU support has been dropped from nouveau > (thus far, nor ever, I expect). Did you update anything other than the > kernel? > > Cheers, > > -ilia > > On Thu, Jan 30, 2020 at 7:27 AM Dave wrote: > >> Not sure if this is the correct forum for this question / issue so please >> feel free to redirect me to an appropriate list. >> >> My driver and graphics card information is below. This configuration has >> been working great (much better than the nvidia proprietary driver) until I >> upgraded from kernel 5.0 to 5.3. The desktop keeps hanging every few >> minutes (the mouse usually keeps working but windows, desktop, task bar >> doesn't). I noticed other threads referencing the nvidia driver having >> issues with the 5.3 kernel as well. Is this a known issue for the nouveau >> driver? If it is is there a fix coming for this? Does it support this card >> with the 5.3 kernel? >> >> >> Thanks and let me know if you need any additional information. I have >> currently backed out that kernel update but can reinstall if you need >> additional details. >> >> >> ___ >> Nouveau mailing list >> Nouveau@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/nouveau >> > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] G84 with kernel 5.3 hanging issues
This is not a known issue. No GPU support has been dropped from nouveau (thus far, nor ever, I expect). Did you update anything other than the kernel? Cheers, -ilia On Thu, Jan 30, 2020 at 7:27 AM Dave wrote: > Not sure if this is the correct forum for this question / issue so please > feel free to redirect me to an appropriate list. > > My driver and graphics card information is below. This configuration has > been working great (much better than the nvidia proprietary driver) until I > upgraded from kernel 5.0 to 5.3. The desktop keeps hanging every few > minutes (the mouse usually keeps working but windows, desktop, task bar > doesn't). I noticed other threads referencing the nvidia driver having > issues with the 5.3 kernel as well. Is this a known issue for the nouveau > driver? If it is is there a fix coming for this? Does it support this card > with the 5.3 kernel? > > > Thanks and let me know if you need any additional information. I have > currently backed out that kernel update but can reinstall if you need > additional details. > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] System freeze: Debian Testing with C61 [GeForce 7025 / nForce 630a]
On Wed, Jan 29, 2020 at 5:03 AM riveravaldez wrote: > > On 12/11/18, Ilia Mirkin wrote: > > On Tue, Dec 11, 2018 at 11:16 AM riveravaldez > > wrote: > > > >> The freezes appears randomly, in every situation, and not when I > >> launch some 3D applications or anything similar. > > > > Try removing nouveau_dri.so -- that will ensure no 3d accel is used, > > while keeping your 2d accel provided by the nouveau ddx. > > Sorry if it's wrong to continue this old thread, but after a good > amount of testing (+1 year) I can confirm that both the problem and > the solution where the mentioned ones. > > The problem (random full-system freezes) persists without change, > identical. And removing nouveau_dri.so from > /usr/lib/x86_64-linux-gnu/dri/ effectively fixes it completely > (leaving aside any lost of performance and some warning messages in > system upgrades and programs launching[1]). > > So, after a GREAT thank-you to Ilia, I consult: > > 1. Is this something that could be fixed? Can I do anything to help? > > 2. If the only possible/viable solution is the mentioned one (remove > nouveau_dri.so), which would be the proper way to make it permanent? > > 2'. In many dist-upgrades the nouveau_dri.so file is re-created in the > same folder, what would be a clean/neat way to handle this? > > Thanks A LOT again. > > [1] A lot of lines like these on some dist-upgrades: > > W: Possible missing firmware > /lib/firmware/nvidia/gp100/gr/sw_method_init.bin for module nouveau > W: Possible missing firmware > /lib/firmware/nvidia/gp100/gr/sw_bundle_init.bin for module nouveau > W: Possible missing firmware > /lib/firmware/nvidia/gp100/gr/sw_nonctx.bin for module nouveau > (...) Sounds like your initramfs builder tries to include these but they're not available on your filesystem. As long as you're not plugging a Pascal GPU into your system, you're fine. > > And a lot of programs producing messages like these on start: > > libGL error: unable to load driver: nouveau_dri.so > libGL error: driver pointer missing > libGL error: failed to load driver: nouveau H annoying. I hadn't considered that. I could add an option to the DDX which makes the default driver "swrast" or something. I also wonder if just not loading the "glx" and "dri2" X modules would be sufficient to get rid of these. You can also stick LIBGL_ALWAYS_SOFTWARE=1 into your /etc/environment (or whatever location causes that env var to appear everywhere) which will force it to use swrast. (With the added benefit of being able to unset it for the programs where you really do want 3d accel.) As for a more permanent fix, one could invest developer attention to the nv30 gallium driver, but that one would first have to be located. I'd be happy to provide some limited mentoring in such a case. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Display broken after resume from suspend
Hi Joshua, Not a fix for your issue, but Ben noticed this (and fixed it): https://github.com/skeggsb/nouveau/commit/024bda7d2b0c3b0731433d60a494c78ab58cb216 which is what causes us to even try 540MB/s link training. However with this fix applied, it'll just give up faster. I'm told eDP is generally a single lane, and you're trying to get more than 270MB/s. So ... the question is ... why is it trying to do 10bpc. One likely reason is that the display_info.bpc == 0 for some reason (and we, rather questionably, default to 10bpc for bandwidth determination). There's no concrete theory as to what that reason might be, but it would explain what's going on. After resuming into a bad state, can you grab the contents of /sys/class/drm/card0-eDP-1/edid (you'll have to cat it or something)? My hope is that it's somehow messed up. Also, can you add "drm.debug=0x1e" to the boot cmd line, in addition to the bits you have already? Should provide some more info, perhaps some of it will even be relevant. Thanks, -ilia On Mon, Jan 13, 2020 at 6:48 PM Joshua J. Kugler wrote: > > I've added debugging command-line parameters to the kernel command line, per > skeggsb and imirkin on #nouveau. > > root@joyful:~# cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-5.3.0-26-generic root=/dev/mapper/vgubuntu-root ro quiet > splash log_buf_len=8M nouveau.debug=disp=trace,bios=trace,i2c=trace 3 > > On this particular run, closing the lid and then opening got me back to the > console, but then I tried running > > echo mem > /sys/power/state > > and it did not recover from that. That is, the laptop is awake, I can ssh in, > screen back-light is on; black screen. > > j > > > On Sunday, January 12, 2020 2:02:00 PM AKST Joshua J. Kugler wrote: > > Howdy! I've been doing a lot of troubleshooting, and haven't arrived at a > > solution yet. > > > > Kernel log attached. VBIOS also attached. > > Ubuntu 19.10 > > > > $ uname -a > > Linux joyful 5.3.0-26-generic #28-Ubuntu SMP Wed Dec 18 05:37:46 UTC 2019 > > x86_64 x86_64 x86_64 GNU/Linux > > $ dpkg -l|grep nouveau > > ii libdrm-nouveau2:amd64 2.4.99-1ubuntu1 > > amd64Userspace interface to nouveau-specific kernel DRM services -- > > runtime > > ii xserver-xorg-video-nouveau 1:1.0.16-1 > > amd64X.Org X server -- Nouveau display driver > > $ lspci |grep VGA > > 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS 3100M] > > (rev a2) > > > > This is a Dell Latitude E6510, so not exactly bleeding edge. :) > > > > The system boots just fine, and I can use the laptop without issue. Goes to > > sleep just fine. When I resume from sleep, the display is black, and will > > not come to life (the back light is on, though). I can ssh in, and run all > > kinds of commands; restart the display manager does *not* bring it back to > > life. > > > > Any tips would be greatly appreciated. > > > > j > > > -- > Joshua J. Kugler - Fairbanks, Alaska - jos...@azariah.com > Azariah Enterprises - Programming and Website Design > PGP Key: http://pgp.mit.edu/ ID > 0x68108cbb73b13b6a___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: declare constants as unsigned long.
Probably want ULL for 32-bit arches to be correct here too.
On Tue, Dec 31, 2019 at 3:53 PM Wambui Karuga wrote:
>
> Explicitly declare constants are unsigned long to address the following
> sparse warnings:
> warning: constant is so big it is long
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> index ac87a3b6b7c9..506b358fcdb6 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> @@ -655,7 +655,7 @@ gf100_ram_new_(const struct nvkm_ram_func *func,
>
> static const struct nvkm_ram_func
> gf100_ram = {
> - .upper = 0x02,
> + .upper = 0x02UL,
> .probe_fbp = gf100_ram_probe_fbp,
> .probe_fbp_amount = gf100_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> index 70a06e3cd55a..3bc39895bbce 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> @@ -43,7 +43,7 @@ gf108_ram_probe_fbp_amount(const struct nvkm_ram_func
> *func, u32 fbpao,
>
> static const struct nvkm_ram_func
> gf108_ram = {
> - .upper = 0x02,
> + .upper = 0x02UL,
> .probe_fbp = gf100_ram_probe_fbp,
> .probe_fbp_amount = gf108_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> index 456aed1f2a02..d01f32c0956a 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> @@ -1698,7 +1698,7 @@ gk104_ram_new_(const struct nvkm_ram_func *func, struct
> nvkm_fb *fb,
>
> static const struct nvkm_ram_func
> gk104_ram = {
> - .upper = 0x02,
> + .upper = 0x02UL,
> .probe_fbp = gf100_ram_probe_fbp,
> .probe_fbp_amount = gf108_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> index 27c68e3f9772..e24ac664eb15 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> @@ -33,7 +33,7 @@ gm107_ram_probe_fbp(const struct nvkm_ram_func *func,
>
> static const struct nvkm_ram_func
> gm107_ram = {
> - .upper = 0x10,
> + .upper = 0x10UL,
> .probe_fbp = gm107_ram_probe_fbp,
> .probe_fbp_amount = gf108_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> index 6b0cac1fe7b4..17994cbda54b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> @@ -48,7 +48,7 @@ gm200_ram_probe_fbp_amount(const struct nvkm_ram_func
> *func, u32 fbpao,
>
> static const struct nvkm_ram_func
> gm200_ram = {
> - .upper = 0x10,
> + .upper = 0x10UL,
> .probe_fbp = gm107_ram_probe_fbp,
> .probe_fbp_amount = gm200_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> index adb62a6beb63..7a07a6ed4578 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> @@ -79,7 +79,7 @@ gp100_ram_probe_fbpa(struct nvkm_device *device, int fbpa)
>
> static const struct nvkm_ram_func
> gp100_ram = {
> - .upper = 0x10,
> + .upper = 0x10UL,
> .probe_fbp = gm107_ram_probe_fbp,
> .probe_fbp_amount = gm200_ram_probe_fbp_amount,
> .probe_fbpa_amount = gp100_ram_probe_fbpa,
> --
> 2.17.1
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Flickering Nvidia GeForce GT210
That's rather odd ... a reclock should not persist across a reboot. On Fri, Dec 27, 2019 at 7:51 PM Jairo Quintanilla wrote: > Hi again. > > I made echo 0f > /sys/kernel/debug/dri/0/pstate and then reboot the > system. > > And, flickering disappear completely, I just have some tearing when > something it's moving a lot in videos. > > Definitely it was the solution for flickering issue. > > Have a nice day 😊 > > Enviado desde mi Samsung Mobile de Claro > > > Original message > From: Ilia Mirkin > Date: 12/27/19 7:50 AM (GMT-06:00) > To: Jairo Quintanilla > Cc: nouveau@lists.freedesktop.org > Subject: Re: [Nouveau] Flickering Nvidia GeForce GT210 > > Hm, this kind of "incomplete fill" flicker could be due to something > just not being able to keep up. But you may be in luck - nouveau may > support reclocking on your GPU -- check the contents > /sys/kernel/debug/dri/0/pstate for the various options, and echo e.g. > "0f" or "22" or whatever the desired level is listed as back into that > file (note - AC = "current", not an actual level). > > On Fri, Dec 27, 2019 at 8:45 AM Jairo Quintanilla > wrote: > > > > The issue is like this.: > > > > https://youtu.be/4YQSL3xWrJA > > > > I have some tearing and sometimes flickering, just screen off and on > suddenly in shorts periods of time. > > > > I have this problem with videos in YouTube using Firefox, and local > videos using vlc and MPlayer for example. > > > > > > Enviado desde mi Samsung Mobile de Claro > > > > > > > > Original message > > From: Ilia Mirkin > > Date: 12/27/19 7:40 AM (GMT-06:00) > > To: Jairo Quintanilla > > Cc: nouveau@lists.freedesktop.org > > Subject: Re: [Nouveau] Flickering Nvidia GeForce GT210 > > > > And when you say "flickering", do you really mean some kind of > > decoding failure with blocks being off or whatever? Or maybe a frame > > ordering issue (where old frames appear instead of new ones > > sometimes)? Or just regular tearing? > > > > Is your video player using GL output, VDPAU output (and vdpau > > decoding), or Xv? (What video player are you using?) > > > > On Fri, Dec 27, 2019 at 8:33 AM Jairo Quintanilla > > wrote: > > > > > > I'm using xorg and nouveau, not modesetting. > > > > > > > > > Thanks for your response. > > > > > > > > > > > > Enviado desde mi Samsung Mobile de Claro > > > > > > > > > > > > Original message > > > From: Ilia Mirkin > > > Date: 12/27/19 7:31 AM (GMT-06:00) > > > To: Jairo Quintanilla > > > Cc: nouveau@lists.freedesktop.org > > > Subject: Re: [Nouveau] Flickering Nvidia GeForce GT210 > > > > > > Are you on Xorg or wayland of some sort? If on Xorg, which DDX are you > > > using -- nouveau or modesetting? > > > > > > On Fri, Dec 27, 2019 at 3:13 AM Jairo Quintanilla > > > wrote: > > > > > > > > Hi mates, > > > > > > > > First to all thanks for your help. > > > > > > > > I've installed Nouveau driver for my Nvidia GeForce GT210 using > Archlinux, but I have some flickering issues when playing videos, only in > the video windows. > > > > > > > > Sometimes I can see some flickering when scrolling. > > > > > > > > Please help. I don't know how to fix it. > > > > > > > > > > > > Atte. Jairo Quintanilla > > > > ___ > > > > Nouveau mailing list > > > > Nouveau@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/nouveau > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Flickering Nvidia GeForce GT210
Hm, this kind of "incomplete fill" flicker could be due to something just not being able to keep up. But you may be in luck - nouveau may support reclocking on your GPU -- check the contents /sys/kernel/debug/dri/0/pstate for the various options, and echo e.g. "0f" or "22" or whatever the desired level is listed as back into that file (note - AC = "current", not an actual level). On Fri, Dec 27, 2019 at 8:45 AM Jairo Quintanilla wrote: > > The issue is like this.: > > https://youtu.be/4YQSL3xWrJA > > I have some tearing and sometimes flickering, just screen off and on suddenly > in shorts periods of time. > > I have this problem with videos in YouTube using Firefox, and local videos > using vlc and MPlayer for example. > > > Enviado desde mi Samsung Mobile de Claro > > > > Original message > From: Ilia Mirkin > Date: 12/27/19 7:40 AM (GMT-06:00) > To: Jairo Quintanilla > Cc: nouveau@lists.freedesktop.org > Subject: Re: [Nouveau] Flickering Nvidia GeForce GT210 > > And when you say "flickering", do you really mean some kind of > decoding failure with blocks being off or whatever? Or maybe a frame > ordering issue (where old frames appear instead of new ones > sometimes)? Or just regular tearing? > > Is your video player using GL output, VDPAU output (and vdpau > decoding), or Xv? (What video player are you using?) > > On Fri, Dec 27, 2019 at 8:33 AM Jairo Quintanilla > wrote: > > > > I'm using xorg and nouveau, not modesetting. > > > > > > Thanks for your response. > > > > > > > > Enviado desde mi Samsung Mobile de Claro > > > > > > > > Original message > > From: Ilia Mirkin > > Date: 12/27/19 7:31 AM (GMT-06:00) > > To: Jairo Quintanilla > > Cc: nouveau@lists.freedesktop.org > > Subject: Re: [Nouveau] Flickering Nvidia GeForce GT210 > > > > Are you on Xorg or wayland of some sort? If on Xorg, which DDX are you > > using -- nouveau or modesetting? > > > > On Fri, Dec 27, 2019 at 3:13 AM Jairo Quintanilla > > wrote: > > > > > > Hi mates, > > > > > > First to all thanks for your help. > > > > > > I've installed Nouveau driver for my Nvidia GeForce GT210 using > > > Archlinux, but I have some flickering issues when playing videos, only in > > > the video windows. > > > > > > Sometimes I can see some flickering when scrolling. > > > > > > Please help. I don't know how to fix it. > > > > > > > > > Atte. Jairo Quintanilla > > > ___ > > > Nouveau mailing list > > > Nouveau@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Flickering Nvidia GeForce GT210
And when you say "flickering", do you really mean some kind of decoding failure with blocks being off or whatever? Or maybe a frame ordering issue (where old frames appear instead of new ones sometimes)? Or just regular tearing? Is your video player using GL output, VDPAU output (and vdpau decoding), or Xv? (What video player are you using?) On Fri, Dec 27, 2019 at 8:33 AM Jairo Quintanilla wrote: > > I'm using xorg and nouveau, not modesetting. > > > Thanks for your response. > > > > Enviado desde mi Samsung Mobile de Claro > > > > Original message > From: Ilia Mirkin > Date: 12/27/19 7:31 AM (GMT-06:00) > To: Jairo Quintanilla > Cc: nouveau@lists.freedesktop.org > Subject: Re: [Nouveau] Flickering Nvidia GeForce GT210 > > Are you on Xorg or wayland of some sort? If on Xorg, which DDX are you > using -- nouveau or modesetting? > > On Fri, Dec 27, 2019 at 3:13 AM Jairo Quintanilla > wrote: > > > > Hi mates, > > > > First to all thanks for your help. > > > > I've installed Nouveau driver for my Nvidia GeForce GT210 using Archlinux, > > but I have some flickering issues when playing videos, only in the video > > windows. > > > > Sometimes I can see some flickering when scrolling. > > > > Please help. I don't know how to fix it. > > > > > > Atte. Jairo Quintanilla > > ___ > > Nouveau mailing list > > Nouveau@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Flickering Nvidia GeForce GT210
Are you on Xorg or wayland of some sort? If on Xorg, which DDX are you using -- nouveau or modesetting? On Fri, Dec 27, 2019 at 3:13 AM Jairo Quintanilla wrote: > > Hi mates, > > First to all thanks for your help. > > I've installed Nouveau driver for my Nvidia GeForce GT210 using Archlinux, > but I have some flickering issues when playing videos, only in the video > windows. > > Sometimes I can see some flickering when scrolling. > > Please help. I don't know how to fix it. > > > Atte. Jairo Quintanilla > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Support for older GPU
Nouveau should work largely OK, although the Tesla series (to which your card belongs) has some unfortunate random hang issues due to what we suspect is an incorrect FIFO channel switch procedure. Support should already exist in any linux distro, so as long as you don't do anything to proactively disable that support, it should work out of the box. You can try with a live cd or something if you don't want to commit. Cheers, -ilia On Fri, Dec 27, 2019 at 3:13 AM Jerry Sanders wrote: > > Hello, Name's Jerry. I have GeForce 8500 GT on my computer and I found out > that Nvidia does not support my GPU anymore for linux. I wanted to ask you > several questions. > 1. Will your team support drivers for old GPUs on new Linux distros? > 2. How can I make a driver work on a kernel that is not meant to work on? > 3. Can I somehow solve this problem without updating my card, which i can't > do due to lack or cash. > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Tracking down severe regression in 5.3-rc4/5.4 for TU116 - assistance needed
Let's add Mika and Rafael, as they were responsible for that commit. Mika/Rafael - any ideas? The commit in question is 0617bdede5114a0002298b12cd0ca2b0cfd0395d Marcin -- would be nice if you could confirm that taking a recent kernel + "git revert 0617bdede5114a0002298b12cd0ca2b0cfd0395d" works well for you. On Thu, Dec 19, 2019 at 3:27 PM Marcin Zajączkowski wrote: > > On 2019-12-16 19:45, Ilia Mirkin wrote: > > The obvious candidate based on a quick scan is > > 0acf5676dc0ffe0683543a20d5ecbd112af5b8ee -- it merges a fix that > > messes with PCI stuff, and there lie dragons. You could try building > > that commit, and if things still work, then I have no idea (and you've > > Nice shot Ilia! > > I managed to build kernel from suspected bd112af5b8ee and it fails Took me a while, but this is the end of the hash. Normally you list the start of the hash (and that's what all the git tools accept). In this case this is commit 0acf5676dc0ffe0683543a20d5ecbd112af5b8ee > miserably (as previously described). The build from the previous commit > 86a04561920b works fine. e577dc152e232c78e5774e4c9b5486a04561920b > > > narrowed the range). Also I'd recommend ensuring that the good kernel > > is really good and the bad kernel is really bad -- boot them a few > > times. > > Well, this problem is reproducible in 100% in newer kernels. I see the > errors on boot logs and after login to Gnome Shell the first execution > of xrandr (or opening a lid) hangs the system (the graphic card). On the > other side I haven't seen that problem in any earlier kernel. Therefore, > the situation is rather clear in my case. Nevertheless, I will stay with > that self-build good kernel (5.3.0-0.rc3 + git) to check it further. > > > How would you see it, Ilia? Is there anything in nouveau that needs to > be adjusted to that changes or rather those changes break something in > nouveau that would be best to fix/revert them (and it would be good to > let the committer know about the problem)? > > Marcin > > > > > On Mon, Dec 16, 2019 at 12:42 PM Marcin Zajączkowski wrote: > >> > >> On 2019-12-16 18:08, Ilia Mirkin wrote: > >>> Hi Marcin, > >>> > >>> You should do a git bisect rather than guessing about commits. I > >>> suspect that searching for "kernel git bisect fedora" should prove > >>> instructive if you're not sure how to do this. > >> > >> Thanks for your suggestion. I realize that I can do it at the Git level > >> and it is the ultimate way to go. However, building the kernel version > >> from sources takes some time (in addition to a regular time needed to > >> install/restart/verify which I already experienced narrowing down to a > >> "just" ~250 commits). > >> > >> Therefore, I would be really thankful for a suggestion which commits > >> could be good to check first - having 2, 4 is better than 8-10 (assuming > >> someone is right :) ). > >> > >> Marcin > >> > >> > >> > >>> On Mon, Dec 16, 2019 at 11:42 AM Marcin Zajączkowski wrote: > >>>> > >>>> Hi, > >>>> > >>>> I've encountered a severe regression in TU116 (probably also TU117) > >>>> introduced in 5.3-rc4 (valid also for recent 5.4.2) [1]. The system > >>>> usually hangs on the subsequent graphic mode related operation (calling > >>>> xrandr after login is enough) with the following error: > >>>> > >>>>> kernel: nouveau :01:00.0: fifo: SCHED_ERROR 08 [] > >>>> ... > >>>>> kernel: nouveau :01:00.0: DRM: failed to idle channel 0 [DRM] > >>>>> kernel: nouveau :01:00.0: i2c: aux 0007: begin idle timeout > >>>>> kernel: nouveau :01:00.0: tmr: stalled at > >>>>> kernel: [ cut here ] > >>>>> kernel: nouveau :01:00.0: timeout > >>>>> kernel: WARNING: CPU: 10 PID: 384 at > >>>>> drivers/gpu/drm/nouveau/nvkm/subdev/bar/g84.c:35 g84_bar_flush+0xcf/> > >>>>> 0xe0 [nouveau] > >>>> > >>>> (detailed log in a corresponding issue - [1]) > >>>> > >>>> With earlier kernels there was no hardware acceleration for NVidia GTX > >>>> 1660 Ti, but at least I could use nouveau to disable it (to save > >>>> battery, trees and lower temperature) or even have an external output > >>>> (with Wayland). Now, the system is
Re: [Nouveau] Tracking down severe regression in 5.3-rc4/5.4 for TU116 - assistance needed
The obvious candidate based on a quick scan is 0acf5676dc0ffe0683543a20d5ecbd112af5b8ee -- it merges a fix that messes with PCI stuff, and there lie dragons. You could try building that commit, and if things still work, then I have no idea (and you've narrowed the range). Also I'd recommend ensuring that the good kernel is really good and the bad kernel is really bad -- boot them a few times. Cheers, -ilia On Mon, Dec 16, 2019 at 12:42 PM Marcin Zajączkowski wrote: > > On 2019-12-16 18:08, Ilia Mirkin wrote: > > Hi Marcin, > > > > You should do a git bisect rather than guessing about commits. I > > suspect that searching for "kernel git bisect fedora" should prove > > instructive if you're not sure how to do this. > > Thanks for your suggestion. I realize that I can do it at the Git level > and it is the ultimate way to go. However, building the kernel version > from sources takes some time (in addition to a regular time needed to > install/restart/verify which I already experienced narrowing down to a > "just" ~250 commits). > > Therefore, I would be really thankful for a suggestion which commits > could be good to check first - having 2, 4 is better than 8-10 (assuming > someone is right :) ). > > Marcin > > > > > On Mon, Dec 16, 2019 at 11:42 AM Marcin Zajączkowski wrote: > >> > >> Hi, > >> > >> I've encountered a severe regression in TU116 (probably also TU117) > >> introduced in 5.3-rc4 (valid also for recent 5.4.2) [1]. The system > >> usually hangs on the subsequent graphic mode related operation (calling > >> xrandr after login is enough) with the following error: > >> > >>> kernel: nouveau :01:00.0: fifo: SCHED_ERROR 08 [] > >> ... > >>> kernel: nouveau :01:00.0: DRM: failed to idle channel 0 [DRM] > >>> kernel: nouveau :01:00.0: i2c: aux 0007: begin idle timeout > >>> kernel: nouveau :01:00.0: tmr: stalled at > >>> kernel: [ cut here ] > >>> kernel: nouveau :01:00.0: timeout > >>> kernel: WARNING: CPU: 10 PID: 384 at > >>> drivers/gpu/drm/nouveau/nvkm/subdev/bar/g84.c:35 g84_bar_flush+0xcf/> > >>> 0xe0 [nouveau] > >> > >> (detailed log in a corresponding issue - [1]) > >> > >> With earlier kernels there was no hardware acceleration for NVidia GTX > >> 1660 Ti, but at least I could use nouveau to disable it (to save > >> battery, trees and lower temperature) or even have an external output > >> (with Wayland). Now, the system is unusable with nouveau :(. > >> > >> I spent some time trying to narrow the scope using on the existing > >> kernel builds for Fedora. I was able to determine that the problem was > >> introduced between 5.3.0-0.rc3.git1.1 (commit 33920f1ec5bf - works fine) > >> and 5.3.0-0.rc4.git0.1 (tag v5.3-rc4 - fails with errors). > >> > >> It's just a few days (7-11 Aug) and "only" around 250 commits. I went > >> through them, but (based on the commits name) I haven't seen any nouveau > >> related changes and in general no very suspected drm related changes. > >> > >>> git log 33920f1ec5bf..v5.3-rc4 --stat > >> > >> > >> Maybe some of more nouveau/drm-experienced developers could take a look > >> at that to determine which commit could break it (to make it easier to > >> find out what should be fixed to prevent that regression)? > >> > >> > >> [1] - > >> https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/516 > >> > >> Thanks in advance > >> Marcin > >> ___ > >> Nouveau mailing list > >> Nouveau@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Tracking down severe regression in 5.3-rc4/5.4 for TU116 - assistance needed
Hi Marcin, You should do a git bisect rather than guessing about commits. I suspect that searching for "kernel git bisect fedora" should prove instructive if you're not sure how to do this. Cheers, -ilia On Mon, Dec 16, 2019 at 11:42 AM Marcin Zajączkowski wrote: > > Hi, > > I've encountered a severe regression in TU116 (probably also TU117) > introduced in 5.3-rc4 (valid also for recent 5.4.2) [1]. The system > usually hangs on the subsequent graphic mode related operation (calling > xrandr after login is enough) with the following error: > > > kernel: nouveau :01:00.0: fifo: SCHED_ERROR 08 [] > ... > > kernel: nouveau :01:00.0: DRM: failed to idle channel 0 [DRM] > > kernel: nouveau :01:00.0: i2c: aux 0007: begin idle timeout > > kernel: nouveau :01:00.0: tmr: stalled at > > kernel: [ cut here ] > > kernel: nouveau :01:00.0: timeout > > kernel: WARNING: CPU: 10 PID: 384 at > > drivers/gpu/drm/nouveau/nvkm/subdev/bar/g84.c:35 g84_bar_flush+0xcf/> 0xe0 > > [nouveau] > > (detailed log in a corresponding issue - [1]) > > With earlier kernels there was no hardware acceleration for NVidia GTX > 1660 Ti, but at least I could use nouveau to disable it (to save > battery, trees and lower temperature) or even have an external output > (with Wayland). Now, the system is unusable with nouveau :(. > > I spent some time trying to narrow the scope using on the existing > kernel builds for Fedora. I was able to determine that the problem was > introduced between 5.3.0-0.rc3.git1.1 (commit 33920f1ec5bf - works fine) > and 5.3.0-0.rc4.git0.1 (tag v5.3-rc4 - fails with errors). > > It's just a few days (7-11 Aug) and "only" around 250 commits. I went > through them, but (based on the commits name) I haven't seen any nouveau > related changes and in general no very suspected drm related changes. > > > git log 33920f1ec5bf..v5.3-rc4 --stat > > > Maybe some of more nouveau/drm-experienced developers could take a look > at that to determine which commit could break it (to make it easier to > find out what should be fixed to prevent that regression)? > > > [1] - > https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/516 > > Thanks in advance > Marcin > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] drm/nouveau: Support NVIDIA format modifiers
On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote:
>
> Allow setting the block layout of a nouveau FB
> object using DRM format modifiers. When
> specified, the format modifier block layout and
> kind overrides the GEM buffer's implicit layout
> and kind. The specified format modifier is
> validated against he list of modifiers supported
> by the target display hardware.
>
> Signed-off-by: James Jones
> ---
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 8 +--
> drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++-
> drivers/gpu/drm/nouveau/nouveau_display.h | 2 +
> 3 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> index 70ad64cb2d34..06c1b18479c1 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> @@ -43,7 +43,7 @@ nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct
> nouveau_framebuffer *fb)
> {
> struct nouveau_drm *drm = nouveau_drm(fb->base.dev);
> struct nv50_wndw_ctxdma *ctxdma;
> - const u8kind = fb->nvbo->kind;
> + const u8kind = fb->kind;
> const u32 handle = 0xfb00 | kind;
> struct {
> struct nv_dma_v0 base;
> @@ -243,7 +243,7 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw,
> bool modeset,
> if (asyw->state.fb != armw->state.fb || !armw->visible || modeset) {
> asyw->image.w = fb->base.width;
> asyw->image.h = fb->base.height;
> - asyw->image.kind = fb->nvbo->kind;
> + asyw->image.kind = fb->kind;
>
> ret = nv50_wndw_atomic_check_acquire_rgb(asyw);
> if (ret) {
> @@ -255,9 +255,9 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw,
> bool modeset,
> if (asyw->image.kind) {
> asyw->image.layout = 0;
> if (drm->client.device.info.chipset >= 0xc0)
> - asyw->image.blockh = fb->nvbo->mode >> 4;
> + asyw->image.blockh = fb->tile_mode >> 4;
> else
> - asyw->image.blockh = fb->nvbo->mode;
> + asyw->image.blockh = fb->tile_mode;
> asyw->image.blocks[0] = fb->base.pitches[0] / 64;
> asyw->image.pitch[0] = 0;
> } else {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index f1509392d7b7..351b58410e1a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -224,6 +224,50 @@ static const struct drm_framebuffer_funcs
> nouveau_framebuffer_funcs = {
> .create_handle = nouveau_user_framebuffer_create_handle,
> };
>
> +static int
> +nouveau_decode_mod(struct nouveau_drm *drm,
> + uint64_t modifier,
> + uint32_t *tile_mode,
> + uint8_t *kind)
> +{
> + struct nouveau_display *disp = nouveau_display(drm->dev);
> + int mod;
> +
> + BUG_ON(!tile_mode || !kind);
> +
> + if (drm->client.device.info.chipset < 0x50) {
Not a full review, but you want to go off the family (chip_class iirc?
something like that, should be obvious). Sadly 0x67/0x68 are higher
than 0x50 numerically, but are logically part of the nv4x generation.
> + return -EINVAL;
> + }
> +
> + BUG_ON(!disp->format_modifiers);
> +
> + for (mod = 0;
> +(disp->format_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
> +(disp->format_modifiers[mod] != modifier);
> +mod++);
> +
> + if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
> + return -EINVAL;
> +
> + if (modifier == DRM_FORMAT_MOD_LINEAR) {
> + /* tile_mode will not be used in this case */
> + *tile_mode = 0;
> + *kind = 0;
> + } else {
> + /*
> +* Extract the block height and kind from the corresponding
> +* modifier fields. See drm_fourcc.h for details.
> +*/
> + *tile_mode = (uint32_t)(modifier & 0xF);
> + *kind = (uint8_t)((modifier >> 12) & 0xFF);
> +
> + if (drm->client.device.info.chipset >= 0xc0)
> + *tile_mode <<= 4;
> + }
> +
> + return 0;
> +}
> +
> static inline uint32_t
> nouveau_get_width_in_blocks(uint32_t stride)
> {
> @@ -300,6 +344,8 @@ nouveau_framebuffer_new(struct drm_device *dev,
> struct nouveau_framebuffer *fb;
> const struct drm_format_info *info;
> unsigned int width, height, i;
> + uint32_t tile_mode;
> + uint8_t kind;
> int ret;
>
> /* YUV overlays have special requirements pre-NV50 */
> @@ -322,6 +368,18 @@ nouvea
[Nouveau] [PATCH] nv50/ir: mark STORE destination inputs as used
Observed an issue when looking at the code generatedy by the
image-vertex-attrib-input-output piglit test. Even though the test
itself worked fine (due to TIC 0 being used for the image), this needs
to be fixed.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index d62d36008e6..8c429026452 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -1591,6 +1591,12 @@ bool Source::scanInstruction(const struct
tgsi_full_instruction *inst)
if (insn.getOpcode() == TGSI_OPCODE_STORE &&
dst.getFile() != TGSI_FILE_MEMORY) {
info->io.globalAccess |= 0x2;
+
+ if (dst.getFile() == TGSI_FILE_INPUT) {
+// TODO: Handle indirect somehow?
+const int i = dst.getIndex(0);
+info->in[i].mask |= 1;
+ }
}
if (dst.getFile() == TGSI_FILE_OUTPUT) {
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] gm107/ir: fix loading z offset for layered 3d image bindings
Unfortuantely we don't know if a particular load is a real 2d image (as
would be a cube face or 2d array element), or a layer of a 3d image.
Since we pass in the TIC reference, the instruction's type has to match
what's in the TIC (experimentally). In order to properly support
bindless images, this also can't be done by looking at the current
bindings and generating appropriate code.
As a result all plain 2d loads are converted into a pair of 2d/3d loads,
with appropriate predicates to ensure only one of those actually
executes, and the values are all merged in.
This goes somewhat against the current flow, so for GM107 we do the OOB
handling directly in the surface processing logic. Perhaps the other
gens should do something similar, but that is left to another change.
This fixes dEQP tests like image_load_store.3d.*_single_layer and GL-CTS
tests like shader_image_load_store.non-layered_binding without breaking
anything else.
Signed-off-by: Ilia Mirkin
---
OK, first of all -- to whoever thought that binding single layers of a 3d
image and telling the shader they were regular 2d images was a good idea --
I disagree.
This change feels super super dirty, but I honestly don't see a materially
cleaner way of handling it. Instead of being able to reuse the OOB
handling, it's put in with the coord processing (!), and the surface
conversion function is seriously hacked up.
But splitting it up is harder, since a lot of information has to flow
from stage to stage, like when to do what kind of access, and cloning
the surface op is much easier in the coord processing stage.
.../nouveau/codegen/nv50_ir_emit_gm107.cpp| 34 ++-
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 206 +-
.../nouveau/codegen/nv50_ir_lowering_nvc0.h | 4 +-
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 10 +-
4 files changed, 201 insertions(+), 53 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 6eefe8f0025..e244bd0d610 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
@@ -122,6 +122,8 @@ private:
void emitSAM();
void emitRAM();
+ void emitPSETP();
+
void emitMOV();
void emitS2R();
void emitCS2R();
@@ -690,6 +692,31 @@ CodeEmitterGM107::emitRAM()
* predicate/cc
**/
+void
+CodeEmitterGM107::emitPSETP()
+{
+
+ emitInsn(0x5090);
+
+ switch (insn->op) {
+ case OP_AND: emitField(0x18, 3, 0); break;
+ case OP_OR: emitField(0x18, 3, 1); break;
+ case OP_XOR: emitField(0x18, 3, 2); break;
+ default:
+ assert(!"unexpected operation");
+ break;
+ }
+
+ // emitINV (0x2a);
+ emitPRED(0x27); // TODO: support 3-arg
+ emitINV (0x20, insn->src(1));
+ emitPRED(0x1d, insn->src(1));
+ emitINV (0x0f, insn->src(0));
+ emitPRED(0x0c, insn->src(0));
+ emitPRED(0x03, insn->def(0));
+ emitPRED(0x00);
+}
+
/***
* movement / conversion
**/
@@ -3557,7 +3584,12 @@ CodeEmitterGM107::emitInstruction(Instruction *i)
case OP_AND:
case OP_OR:
case OP_XOR:
- emitLOP();
+ switch (insn->def(0).getFile()) {
+ case FILE_GPR: emitLOP(); break;
+ case FILE_PREDICATE: emitPSETP(); break;
+ default:
+ assert(!"invalid bool op");
+ }
break;
case OP_NOT:
emitNOT();
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 1f702a987d8..0f68a9a229f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -1802,6 +1802,9 @@ NVC0LoweringPass::loadSuInfo32(Value *ptr, int slot,
uint32_t off, bool bindless
{
uint32_t base = slot * NVC0_SU_INFO__STRIDE;
+ // We don't upload surface info for bindless for GM107+
+ assert(!bindless || targ->getChipset() < NVISA_GM107_CHIPSET);
+
if (ptr) {
ptr = bld.mkOp2v(OP_ADD, TYPE_U32, bld.getSSA(), ptr, bld.mkImm(slot));
if (bindless)
@@ -2204,7 +2207,7 @@ getDestType(const ImgType type) {
}
void
-NVC0LoweringPass::convertSurfaceFormat(TexInstruction *su)
+NVC0LoweringPass::convertSurfaceFormat(TexInstruction *su, Instruction
**loaded)
{
const TexInstruction::ImgFormatDesc *format = su->tex.format;
int width = format->bits[0] + format->bits[1] +
@@ -2223,21 +2226,38 @@ NVC0LoweringPass::convertSurfaceFormat(TexInstruction
*su)
if (width < 32)
untypedDst[0] = bld.getSSA();
- for (int i = 0; i < 4; i++) {
- typedDst[i] = su->g
[Nouveau] [PATCH xf86-video-nouveau] dri2, present: move in pixmap before getting addresses
First of all, we were not forcing the pixmap to be moved in before
attempting to present it. Secondly, in certain configurations, we avoid
ever backing pixmaps with vram (in GPUs with 32MB of VRAM or less).
This fixes the observed cases where we ended up assuming that a bo was
backing a pixmap without doing the explicit move-in.
Signed-off-by: Ilia Mirkin
---
This fixes some crashes on a NV5 with 32MB VRAM + xfwm4 --vblank=present,
however the failure modes (e.g. pixmap doesn't have backing) can happen
anywhere I believe, just much less likely.
src/nouveau_dri2.c| 18 +++---
src/nouveau_present.c | 15 ++-
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index ce0a573..8c29eca 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -248,9 +248,13 @@ static uint64_t dri2_sequence;
static Bool
update_front(DrawablePtr draw, DRI2BufferPtr front)
{
- int r;
- PixmapPtr pixmap;
+ ScrnInfoPtr scrn = xf86ScreenToScrn(draw->pScreen);
+ NVPtr pNv = NVPTR(scrn);
struct nouveau_dri2_buffer *nvbuf = nouveau_dri2_buffer(front);
+ struct nouveau_bo *pixmap_bo;
+
+ PixmapPtr pixmap;
+ int r;
if (draw->type == DRAWABLE_PIXMAP)
pixmap = (PixmapPtr)draw;
@@ -259,8 +263,16 @@ update_front(DrawablePtr draw, DRI2BufferPtr front)
pixmap->refcnt++;
+ pNv->exa_force_cp = TRUE;
exaMoveInPixmap(pixmap);
- r = nouveau_bo_name_get(nouveau_pixmap_bo(pixmap), &front->name);
+ pNv->exa_force_cp = FALSE;
+ pixmap_bo = nouveau_pixmap_bo(pixmap);
+
+ if (!pixmap_bo)
+ r = -1;
+ else
+ r = nouveau_bo_name_get(pixmap_bo, &front->name);
+
if (r) {
(*draw->pScreen->DestroyPixmap)(pixmap);
return FALSE;
diff --git a/src/nouveau_present.c b/src/nouveau_present.c
index 936475e..8167fd8 100644
--- a/src/nouveau_present.c
+++ b/src/nouveau_present.c
@@ -147,12 +147,25 @@ nouveau_present_flip_check(RRCrtcPtr rrcrtc, WindowPtr
window,
PixmapPtr pixmap, Bool sync_flip)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(window->drawable.pScreen);
+ NVPtr pNv = NVPTR(scrn);
xf86CrtcPtr crtc = rrcrtc->devPrivate;
+ struct nouveau_pixmap *priv = nouveau_pixmap(pixmap);
if (!scrn->vtSema || !drmmode_crtc_on(crtc) || crtc->rotatedData)
return FALSE;
- return TRUE;
+ if (!priv) {
+ /* The pixmap may not have had backing for low-memory GPUs, or
+* if we ran out of VRAM. Make sure it's properly backed for
+* flipping.
+*/
+ pNv->exa_force_cp = TRUE;
+ exaMoveInPixmap(pixmap);
+ pNv->exa_force_cp = FALSE;
+ priv = nouveau_pixmap(pixmap);
+ }
+
+ return priv ? TRUE : FALSE;
}
static void
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH xf86-video-nouveau] nv4/exa: tiling is unsupported pre-nv10, reduce alignment requirements
Commit 8c8f15c9d3 added increased pitch alignment requirements to handle
nv10-nv40 tiling (which must have a small number * PoT pitch). While
NV4/NV5 do have tiling, this was never supported in nouveau.
This change enables 1920x1200 resolutions since the maximum surface
pitch has to be strictly less than 8192. The current logic will align
1920*4 up to 8192 unnecessarily.
Signed-off-by: Ilia Mirkin
Cc: Marcin Kościelnicki
Cc: Francisco Jerez
---
src/nouveau_dri2.c | 5 -
src/nv_driver.c| 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index 3d53785..ce0a573 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -62,7 +62,10 @@ nouveau_dri2_create_buffer2(ScreenPtr pScreen, DrawablePtr
pDraw, unsigned int a
ppix->refcnt++;
} else {
int bpp;
- unsigned int usage_hint = NOUVEAU_CREATE_PIXMAP_TILED;
+ unsigned int usage_hint = 0;
+
+ if (pNv->Architecture >= NV_ARCH_10)
+ usage_hint |= NOUVEAU_CREATE_PIXMAP_TILED;
/* 'format' is just depth (or 0, or maybe it depends on the
caller) */
bpp = round_up_pow2(format ? format : pDraw->depth);
diff --git a/src/nv_driver.c b/src/nv_driver.c
index 42eb9db..a63674c 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -1082,7 +1082,8 @@ NVPreInit(ScrnInfoPtr pScrn, int flags)
pNv->wfb_enabled = xf86ReturnOptValBool(
pNv->Options, OPTION_WFB, FALSE);
- pNv->tiled_scanout = TRUE;
+ if (pNv->Architecture >= NV_ARCH_10)
+ pNv->tiled_scanout = TRUE;
}
pNv->ce_enabled =
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau locking machine solid
On Sun, Sep 29, 2019 at 4:46 AM pete wrote: > > > Hi . > > I am having a very annoying problem not sure where the root of it lies > > When running FLdigi it runs fine for about 10 mineuts then i start > getting errors leading to a complete lock up that needs a power button > to free it up i get the following > > [ 653.080497] nouveau :01:00.0: fifo: DMA_PUSHER - ch 3 This is very much a nouveau problem. We do something wrong when switching channels and the pusher gets upset. This affects Tesla family GPUs (G8x, G9x, GT2xx). No known solution. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Is Nouveau really using the io_reserve_lru?
On Thu, Sep 26, 2019 at 5:44 PM Ben Skeggs wrote: > > On Tue, 24 Sep 2019 at 22:19, Christian König > wrote: > > > > Hi guys, > > > > while working through more old TTM functionality I stumbled over the > > io_reserve_lru. > > > > Basic idea is that when this flag is set the driver->io_mem_reserve() > > callback can return -EAGAIN resulting in unmapping of other BOs. > > > > But Nouveau doesn't seem to return -EAGAIN in the call path of > > io_mem_reserve anywhere. > I believe this is a bug in Nouveau. We *should* be returning -EAGAIN > if we fail to find space in BAR1 to map the BO into. Could this lead to SIGBUS in userspace, esp related to resume and similar situations? A user has been experiencing this in a tricky-to-reproduce scenario with a ton of vram dedicated to framebuffers and so on (3x 4K), and the nouveau ddx falls back to memcpy in certain cases. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 13/36] drm/nouveau: use bpp instead of cpp for drm_format_info
On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang wrote:
>
> cpp[BytePerPlane] can't describe the 10bit data format correctly,
> So we use bpp[BitPerPlane] to instead cpp.
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ---
> drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4 ++--
> drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
> 3 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index f22f010..59d2f07 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -874,11 +874,12 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
>
> /* Update the framebuffer location. */
> regp->fb_start = nv_crtc->fb.offset & ~3;
> - regp->fb_start += (y * drm_fb->pitches[0]) + (x *
> drm_fb->format->cpp[0]);
> + regp->fb_start += (y * drm_fb->pitches[0]) +
> + (x * drm_fb->format->bpp[0] / 8);
> nv_set_crtc_base(dev, nv_crtc->index, regp->fb_start);
>
> /* Update the arbitration parameters. */
> - nouveau_calc_arb(dev, crtc->mode.clock, drm_fb->format->cpp[0] * 8,
> + nouveau_calc_arb(dev, crtc->mode.clock, drm_fb->format->bpp[0],
> &arb_burst, &arb_lwm);
>
> regp->CRTC[NV_CIO_CRE_FF_INDEX] = arb_burst;
> @@ -1238,7 +1239,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
> drm_framebuffer *fb,
>
> /* Initialize a page flip struct */
> *s = (struct nv04_page_flip_state)
> - { { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
> + { { }, event, crtc, fb->format->bpp[0], fb->pitches[0],
> new_bo->bo.offset };
>
> /* Keep vblanks on during flip, for the target crtc of this flip */
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> b/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> index d5e295c..59883bd0 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> @@ -190,12 +190,12 @@ base507c_acquire(struct nv50_wndw *wndw, struct
> nv50_wndw_atom *asyw,
> return ret;
>
> if (!wndw->func->ilut) {
> - if ((asyh->base.cpp != 1) ^ (fb->format->cpp[0] != 1))
> + if (asyh->base.cpp != 1 ^ fb->format->bpp[0] != 8)
Please leave the parens in. Even if it works out to the same thing
(don't know), ^ vs != ordering isn't fresh in many people's minds
(mine included).
> asyh->state.color_mgmt_changed = true;
> }
>
> asyh->base.depth = fb->format->depth;
> - asyh->base.cpp = fb->format->cpp[0];
> + asyh->base.cpp = fb->format->bpp[0] / 8;
> asyh->base.x = asyw->state.src.x1 >> 16;
> asyh->base.y = asyw->state.src.y1 >> 16;
> asyh->base.w = asyw->state.fb->width;
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> b/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> index cc41766..c6c2e0b 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> @@ -135,7 +135,7 @@ ovly507e_acquire(struct nv50_wndw *wndw, struct
> nv50_wndw_atom *asyw,
> if (ret)
> return ret;
>
> - asyh->ovly.cpp = fb->format->cpp[0];
> + asyh->ovly.cpp = fb->format->bpp[0] / 8;
> return 0;
> }
>
> --
> 2.7.4
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul wrote:
>
> When drm_connector_helper_funcs->atomic_best_encoder is defined,
> ->best_encoder is ignored both by the atomic modesetting helpers. That
By both the atomic modesetting helpers and ... (usually "both" implies 2 things)
> being said, this hook is completely broken anyway - it always returns
> the first msto for a given mstc, despite the fact it might already be in
> use.
>
> So, just get rid of it. We'll need this in a moment anyway, when we make
> mstos per-head as opposed to per-connector.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index b46be8a091e9..a3f350fdfa8c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
> *connector,
> return &mstc->mstm->msto[head->base.index]->encoder;
> }
>
> -static struct drm_encoder *
> -nv50_mstc_best_encoder(struct drm_connector *connector)
> -{
> - struct nv50_mstc *mstc = nv50_mstc(connector);
> -
> - return &mstc->mstm->msto[0]->encoder;
> -}
> -
> static enum drm_mode_status
> nv50_mstc_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> @@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
> nv50_mstc_help = {
> .get_modes = nv50_mstc_get_modes,
> .mode_valid = nv50_mstc_mode_valid,
> - .best_encoder = nv50_mstc_best_encoder,
> .atomic_best_encoder = nv50_mstc_atomic_best_encoder,
> .atomic_check = nv50_mstc_atomic_check,
> };
> --
> 2.21.0
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >> > Hi Greg, > >> > > >> > This feels like it's missing a From: line. > >> > > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 > >> > Author: Lyude Paul > >> > Date: Mon Jan 28 16:03:50 2019 -0500 > >> > > >> >drm/nouveau: Don't WARN_ON VCPI allocation failures > >> > > >> > Is this an artifact of your notification-of-patches process and I > >> > never noticed before, or was the patch ingested incorrectly? > >> > >> It was always like this for patches that came through me. Greg's script > >> generates an explicit "From:" line in the patch, but I never saw the > >> value in that since git does the right thing by looking at the "From:" > >> line in the mail header. > >> > >> The right thing is being done in stable-rc and for the releases. For > >> your example here, this is how it looks like in the stable-rc tree: > >> > >> commit bdcc885be68289a37d0d063cd94390da81fd8178 > >> Author: Lyude Paul > >> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > >> Commit: Greg Kroah-Hartman > >> CommitDate: Fri Sep 13 14:05:29 2019 +0100 > >> > >>drm/nouveau: Don't WARN_ON VCPI allocation failures > > > >Yeah, we should fix your scripts to put the explicit From: line in here > >as we are dealing with patches in this format and it causes confusion at > >times (like now.) It's not the first time and that's why I added those > >lines to the patches. > > Heh, didn't think anyone cared about this scenario for the stable-rc > patches. > > I'll go add it. > > But... why do you actually care? Just a hygiene thing. Everyone else sends patches the normal way, with accurate attribution. Why should stable be different? (I was surprised to see Greg contributing to nouveau when I first saw the patch. But then realized it was the stable ingestion notification.) -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46 AM Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >Hi Greg, > > > >This feels like it's missing a From: line. > > > >commit b513a18cf1d705bd04efd91c417e79e4938be093 > >Author: Lyude Paul > >Date: Mon Jan 28 16:03:50 2019 -0500 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > >Is this an artifact of your notification-of-patches process and I > >never noticed before, or was the patch ingested incorrectly? > > It was always like this for patches that came through me. Greg's script > generates an explicit "From:" line in the patch, but I never saw the > value in that since git does the right thing by looking at the "From:" > line in the mail header. That's right -- the email's From header gets used in the case of no explicit From in the email body. But Greg is sending the emails From: Greg, so if I were to ingest that email, I would end up with a patch From: Greg, not From: Lyude as it ought to be. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Hi Greg,
This feels like it's missing a From: line.
commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul
Date: Mon Jan 28 16:03:50 2019 -0500
drm/nouveau: Don't WARN_ON VCPI allocation failures
Is this an artifact of your notification-of-patches process and I
never noticed before, or was the patch ingested incorrectly?
Cheers,
-ilia
On Fri, Sep 13, 2019 at 9:16 AM Greg Kroah-Hartman
wrote:
>
> [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
>
> This is much louder then we want. VCPI allocation failures are quite
> normal, since they will happen if any part of the modesetting process is
> interrupted by removing the DP MST topology in question. So just print a
> debugging message on VCPI failures instead.
>
> Signed-off-by: Lyude Paul
> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
> multi-stream")
> Cc: Ben Skeggs
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: # v4.10+
> Signed-off-by: Ben Skeggs
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index f889d41a281fa..5e01bfb69d7a3 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
>
> slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
> r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn,
> slots);
> - WARN_ON(!r);
> + if (!r)
> + DRM_DEBUG_KMS("Failed to allocate VCPI\n");
>
> if (!mstm->links++)
> nv50_outp_acquire(mstm->outp);
> --
> 2.20.1
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] pci/gk104: wait for ltssm idle before changing the link
On Thu, Sep 12, 2019 at 3:00 PM Karol Herbst wrote:
>
> taken from nvgpu
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/nvkm/subdev/pci/gk104.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c
> b/drm/nouveau/nvkm/subdev/pci/gk104.c
> index 6aeb07fe4..2d1fa67eb 100644
> --- a/drm/nouveau/nvkm/subdev/pci/gk104.c
> +++ b/drm/nouveau/nvkm/subdev/pci/gk104.c
> @@ -23,6 +23,8 @@
> */
> #include "priv.h"
>
> +#include
> +
> static int
> gk104_pcie_version_supported(struct nvkm_pci *pci)
> {
> @@ -142,6 +144,11 @@ gk104_pcie_set_link_speed(struct nvkm_pci *pci, enum
> nvkm_pcie_speed speed)
> break;
> }
>
> + /* wait for ltssm idle */
> + nvkm_msec(device, 200,
> + if ((nvkm_rd32(device, 0x8c040) & 0x1f) == 0)
> + break;
> + );
What if it doesn't idle? Should you still do the below things?
> nvkm_mask(device, 0x8c040, 0xc, mask_value);
> nvkm_mask(device, 0x8c040, 0x1, 0x1);
> }
> --
> 2.21.0
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding wrote: > > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote: > > > > > > Hi, > > > > > > > > Changing the order doesn't look hard. Patch attached (untested, have > > > > > no > > > > > test hardware). But maybe I missed some detail ... > > > > > > > > I came up with something very similar by splitting up nouveau_bo_new() > > > > into allocation and initialization steps, so that when necessary the GEM > > > > object can be initialized in between. I think that's slightly more > > > > flexible and easier to understand than a boolean flag. > > > > > > Yes, that should work too. > > > > > > Acked-by: Gerd Hoffmann > > Acked-by: Ben Skeggs > > Thanks guys, applied to drm-misc-next. Hi Thierry, Initial investigations suggest that this commit currently in drm-next commit 019cbd4a4feb3aa3a917d78e7110e3011bbff6d5 Author: Thierry Reding Date: Wed Aug 14 11:00:48 2019 +0200 drm/nouveau: Initialize GEM object before TTM object breaks nouveau userspace which tries to allocate GEM objects with a non-page-aligned size. Previously nouveau_gem_new would just call nouveau_bo_init which would call nouveau_bo_fixup_align before initializing the GEM object. With this change, it is done after. What do you think -- OK to just move that bit of logic into the new nouveau_bo_alloc() (and make size/align be pointers so that they can be fixed up?) Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau/kms/gf119-: allow both 256- and 1024-sized LUTs to be used
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Signed-off-by: Ilia Mirkin
---
Only tested on G84 and GK208. The GV100+ is entirely untested.
With the fixed modetest tool, setting ilut and olut sizes to different
quantities seems to work out OK, across a range of formats (XR24, XB30,
XB4H).
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 11 ---
drivers/gpu/drm/nouveau/dispnv50/head.c | 14 +-
drivers/gpu/drm/nouveau/dispnv50/head.h | 7 ---
drivers/gpu/drm/nouveau/dispnv50/head507d.c | 9 +++--
drivers/gpu/drm/nouveau/dispnv50/head827d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/head907d.c | 11 ---
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 11 ---
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 12
drivers/gpu/drm/nouveau/dispnv50/lut.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 -
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 3 ++-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 11 ---
drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c | 11 +++
14 files changed, 84 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/base907c.c
b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
index 5f2de77e0f32..224a34c340fe 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/base907c.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
@@ -75,12 +75,16 @@ base907c_xlut_set(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw)
}
}
-static void
-base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw)
+static bool
+base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw, int size)
{
- asyw->xlut.i.mode = 7;
+ if (size != 256 && size != 1024)
+ return false;
+
+ asyw->xlut.i.mode = size == 1024 ? 4 : 7;
asyw->xlut.i.enable = 2;
asyw->xlut.i.load = head907d_olut_load;
+ return true;
}
static inline u32
@@ -160,6 +164,7 @@ base907c = {
.csc_set = base907c_csc_set,
.csc_clr = base907c_csc_clr,
.olut_core = true,
+ .ilut_size = 1024,
.xlut_set = base907c_xlut_set,
.xlut_clr = base907c_xlut_clr,
.image_set = base907c_image_set,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 71c23bf1fe25..42ba68dadb80 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -235,9 +235,13 @@ nv50_head_atomic_check_lut(struct nv50_head *head,
return 0;
}
+ if (!head->func->olut(head, asyh, drm_color_lut_size(olut))) {
+ DRM_DEBUG_KMS("Invalid olut\n");
+ return -EINVAL;
+ }
asyh->olut.handle = disp->core->chan.vram.handle;
asyh->olut.buffer = !asyh->olut.buffer;
- head->func->olut(head, asyh);
+
return 0;
}
@@ -511,11 +515,11 @@ nv50_head_create(struct drm_device *dev, int index)
drm_crtc_init_with_planes(dev, crtc, &base->plane, &curs->plane,
&nv50_head_func, "head-%d", head->base.index);
drm_crtc_helper_add(crtc, &nv50_head_help);
+ /* Keep the legacy gamma size at 256 to avoid compatibility issues */
drm_mode_crtc_set_gamma_size(crtc, 256);
- if (disp->disp->object.oclass >= GF110_DISP)
- drm_crtc_enable_color_mgmt(crtc, 256, true, 256);
- else
- drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
+ drm_crtc_enable_color_mgmt(crtc, base->func->ilut_size,
+ disp->disp->object.oclass >= GF110_DISP,
+ head->func->olut_size);
if (head->func->olut_set) {
ret = nv50_lut_init(disp, &drm->client.mmu, &head->olut);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.h
b/drivers/gpu/drm/nouveau/dispnv50/head.h
index d1c002f534d4..5c2cda2f32a8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.h
@@ -20,8 +20,9 @@ void nv50_head_flush_clr(struct nv50_head *, struct
nv50_head_atom *, bool y);
struct nv50_head_func {
void (*view)(struct nv50_head *, struct nv50_head_atom *);
void (*mode)(struct nv50_head *, struct nv50_head_atom *);
- void (*olut)(struct nv50_head *, struct nv50_head_atom *);
+ bool (*olut)(struct nv50_head *, struct nv50_head_atom *, int);
bool olut_identity;
+ int olut_size;
void (*olut_set)(struct nv50_head *, struct nv50_head_atom *);
void (*olut_clr)(struct nv50_head *);
void (*core_calc)(struct nv50_head *, struct nv50_head_atom *);
@@ -43,7 +44,7 @@ struct nv50_head_func {
extern const st
Re: [Nouveau] [RFC PATCH v2] clk: Remove BYPASS_PLL_CHECK from PLLs
Can you check to see if that bit was set prior to entering the code? I
wonder if you can just restore it if it was there, and leave it if
it's not?
On Wed, Sep 4, 2019 at 10:28 AM Mark Menzynski wrote:
>
> I have looked at problem with Fermi GPUs where changing to higher clock
> led to really bad perfomance (with GpuTest 20x worse perfomance) and later
> also crashes of the nouveau. It seemed
> to be affected by Shader Clock in Voltage Entries in the video BIOS. Disabling
> BYPASS_PLL_CHECK in CLK0_CTRL seems to completely fix the issue. I have
> tried to search this BYPASS_PLL_CHECK in Nvidia traces but seemed it
> wasn't used nowhere for CLK settings.
>
> Removing this works fine, but I don't know what it's really for.
> Actual bit setting this BYPASS_PLL_CHECK is on 0x10:
> lookup -ac0 0x137000 0x10
> PCLOCK.CLK0_CTRL => { BYPASS_PLL_CHECK | UNK12 = 0 }
> Also, disabling this bit on other CLKs doesn't seem to break anything.
>
> v2: Add back PLL lock test
>
> Signed-off-by: Mark Menzynski
> ---
> drm/nouveau/nvkm/subdev/clk/gf100.c | 1 -
> drm/nouveau/nvkm/subdev/clk/gk104.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drm/nouveau/nvkm/subdev/clk/gf100.c
> b/drm/nouveau/nvkm/subdev/clk/gf100.c
> index 7f67f9f5..fe56817b 100644
> --- a/drm/nouveau/nvkm/subdev/clk/gf100.c
> +++ b/drm/nouveau/nvkm/subdev/clk/gf100.c
> @@ -381,7 +381,6 @@ gf100_clk_prog_2(struct gf100_clk *clk, int idx)
> if (nvkm_rd32(device, addr + 0x00) &
> 0x0002)
> break;
> );
> - nvkm_mask(device, addr + 0x00, 0x0010,
> 0x0010);
>
> /* Enable sync mode */
> nvkm_mask(device, addr + 0x00, 0x0004,
> 0x0004);
> diff --git a/drm/nouveau/nvkm/subdev/clk/gk104.c
> b/drm/nouveau/nvkm/subdev/clk/gk104.c
> index 0b37e3da..22cac304 100644
> --- a/drm/nouveau/nvkm/subdev/clk/gk104.c
> +++ b/drm/nouveau/nvkm/subdev/clk/gk104.c
> @@ -400,7 +400,6 @@ gk104_clk_prog_2(struct gk104_clk *clk, int idx)
> if (nvkm_rd32(device, addr + 0x00) & 0x0002)
> break;
> );
> - nvkm_mask(device, addr + 0x00, 0x0010, 0x0010);
>
> /* Enable sync mode */
> nvkm_mask(device, addr + 0x00, 0x0004, 0x0004);
> --
> 2.21.0
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/nouveau: utilize subconnector property for DP
On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä wrote: > > On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote: > > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä > > wrote: > > > > > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote: > > > > This should probably be fixed to account for the scenario where an > > > > HDMI connector is plugged directly into the DP++ port. I don't think > > > > the dp.subconnector property will be valid in that case. > > > > (Unfortunately I don't remember how one detects that particular > > > > situation.) > > > > > > One may or may not be able to detect it very well. I've seen dongles > > > that automagically change the DFP type from DP++ to DP/HDMI depending > > > on what's plugged in, and I've also seen dongles that leave the DFP > > > type to DP++. > > > > Well, our internal logic certainly knows if it's driving DP or TMDS. I > > just don't remember how it knows this. > > You'll be driving DP in this case. The DFP will be the one driving > DP or TMDS depending on what's plugged in. OK. That's not the case I was worried about though :) I'm worried about the case where you plug a true HDMI thing into the DP port, which will then be driven by HDMI and none of the dp.* things will be set (I don't remember, but they might even be in a union). I think Intel multiplies connectors for this, but nouveau/amd just have a single connector that handles both. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/nouveau: utilize subconnector property for DP
On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä wrote: > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote: > > This should probably be fixed to account for the scenario where an > > HDMI connector is plugged directly into the DP++ port. I don't think > > the dp.subconnector property will be valid in that case. > > (Unfortunately I don't remember how one detects that particular > > situation.) > > One may or may not be able to detect it very well. I've seen dongles > that automagically change the DFP type from DP++ to DP/HDMI depending > on what's plugged in, and I've also seen dongles that leave the DFP > type to DP++. Well, our internal logic certainly knows if it's driving DP or TMDS. I just don't remember how it knows this. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v3 5/7] drm/nouveau: utilize subconnector property for DP
This should probably be fixed to account for the scenario where an
HDMI connector is plugged directly into the DP++ port. I don't think
the dp.subconnector property will be valid in that case.
(Unfortunately I don't remember how one detects that particular
situation.)
On Mon, Aug 26, 2019 at 9:22 AM Oleg Vasilev wrote:
>
> Since DP-specific information is stored in driver's structures, every
> driver needs to implement subconnector property by itself.
>
> Reviewed-by: Emil Velikov
> Signed-off-by: Oleg Vasilev
> Cc: Ben Skeggs
> Cc: nouveau@lists.freedesktop.org
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
> drivers/gpu/drm/nouveau/nouveau_dp.c| 9 +
> drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
> 3 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 94dfa2e5a9ab..d9c116cc11b9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -635,6 +635,17 @@ nouveau_connector_detect(struct drm_connector
> *connector, bool force)
> pm_runtime_mark_last_busy(dev->dev);
> pm_runtime_put_autosuspend(dev->dev);
>
> + if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + enum drm_mode_subconnector subconnector =
> DRM_MODE_SUBCONNECTOR_Unknown;
> +
> + if (conn_status == connector_status_connected && nv_encoder)
> + subconnector = nv_encoder->dp.subconnector;
> + drm_object_property_set_value(&connector->base,
> + connector->dev->mode_config.dp_subconnector_property,
> + subconnector);
> + }
> +
> return conn_status;
> }
>
> @@ -1359,6 +1370,8 @@ nouveau_connector_create(struct drm_device *dev,
> kfree(nv_connector);
> return ERR_PTR(ret);
> }
> +
> + drm_mode_add_dp_subconnector_property(connector);
> funcs = &nouveau_connector_funcs;
> break;
> default:
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 2674f1587457..85eac853e3f8 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -62,6 +62,7 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct nvkm_i2c_aux *aux;
> u8 dpcd[8];
> + u8 port_cap[DP_MAX_DOWNSTREAM_PORTS] = {};
> int ret;
>
> aux = nv_encoder->aux;
> @@ -72,6 +73,14 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
> if (ret)
> return ret;
>
> + if (dpcd[DP_DPCD_REV] > 0x10) {
> + ret = nvkm_rdaux(aux, DP_DOWNSTREAM_PORT_0,
> +port_cap, DP_MAX_DOWNSTREAM_PORTS);
> + if (ret)
> + memset(port_cap, 0, DP_MAX_DOWNSTREAM_PORTS);
> + }
> + nv_encoder->dp.subconnector = drm_dp_subconnector_type(dpcd,
> port_cap);
> +
> nv_encoder->dp.link_bw = 27000 * dpcd[1];
> nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
> b/drivers/gpu/drm/nouveau/nouveau_encoder.h
> index 3517f920bf89..e17971a30221 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
> @@ -63,6 +63,7 @@ struct nouveau_encoder {
> struct nv50_mstm *mstm;
> int link_nr;
> int link_bw;
> + enum drm_mode_subconnector subconnector;
> } dp;
> };
>
> --
> 2.23.0
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Video Hardware Decoding: Jittery Rectangles on Nvidia GT218 NVA8 VP4.
On Wed, Aug 14, 2019 at 7:37 AM Ralph Corderoy wrote: > > Hi Ilia, > > A fortnight ago, you wrote: > > > The video plays, CPU load is less (my aim), but there's ‘tearing’ of > > > the picture as if small rectangles that are updates are appearing in > > > the wrong location, off by a little. If I step through the frames > > > with mpv's ‘.’ and ‘,’ then I've found a pattern: one frame's > > > picture is good, followed by N bad ones where N is 3 or 7, i.e. > > > every 4th or 8th frame is okay. Don't know if that's a clue or > > > helps someone here recognise a known problem. > > > > Unfortunately I've never tracked down the cause for this. > > https://nouveau.freedesktop.org/wiki/VideoAcceleration/ - see note #4. > > That sounds like the problem, but it is all the way through TV programme > from the BBC iPlayer's service. Yeah ... there's nothing _intrinsically_ linked to those trailers, and I've definitely seen it on full files as well. At the time I wrote that note, I had primarily seen the issue in movie trailers I downloaded from some h264 demo site. > > > I have, over time, collected some sample videos where this happens in > > the first few frames. The plan was to do mmt traces of the blob > > driver, and figure out what it was doing differently. If this is > > something you're interested in, I'd be happy to provide some guidance. > > I've two mmio traces, nouveau and nvidia, each using mpv(1) to play the > same ten-second extract of an iPlayer MP4, with and without ‘--vo=vdpau > --hwdec=vdpau’. > > $ grep -n ^MARK nvidia-4.mmiotrace > 20:MARK 65645.302939 buffer_size_kb: 524288 > 21:MARK 65645.385776 starting x > 1447554:MARK 65681.979892 x started > 1448560:MARK 65682.446747 mpv none start > 1868197:MARK 65701.153770 mpv none done > 1869462:MARK 65702.748005 mpv vo start > 2633729:MARK 65724.465154 mpv vo done > 2634956:MARK 65726.259829 mpv vo hwdec start > 5347520:MARK 65759.841432 mpv vo hwdec done > 5349019:MARK 65762.431137 killing cat > $ > > hwdec on nvidia easily overflowed the default 1,408 KiB trace buffer, > whereas nouveau didn't. > > Are these helpful? Shall I submit them to the Gmail address given in > https://nouveau.freedesktop.org/wiki/MmioTrace/ Well, this might be presumptuous (given that I never figured out what the issue was), but here was my plan of attack (which, I remind you, I wasn't able to use to figure out the underlying problem): 1. Find an offending file where the problem occurs _early_, preferably first few frames, since slight differences in submissions eventually creep in, esp around reference frame management. 2. Using h264_player (available at https://github.com/imirkin/re-vp2 -- note that it has to have a few parameters hardcoded to a specific file, and requires extraction of the h264 stream first -- see readme), do a mmt (not mmio) trace of nvidia blob and of nouveau (look for valgrind-mmt) 3. Compare and contrast The theory here is that we're setting up the engines correctly, just feeding them incorrect data. If we're setting up the engines incorrectly, then the mmio trace would come in handy. The reason to use h264_player and not a full-featured player is that I don't do any funny business with frame timing, reordering, or anything else extraneous. You can't actually watch a movie with this thing (frame order will give you a headache), but it can be helpful for tracing. Of course a few things have happened in the intervening 6 years since I wrote that tool... (has it really been that long?) The main one being that mmt traces of nouveau no longer work out of the box. You have to edit mesa's winsys/nouveau/drm/nouveau_drm_winsys.c to set drm->nvif = false after the nouveau_drm_new call. That should allow the mmt tracing to be decoded by the demmt tool. Also the demmt tool has bitrotted a fair amount. At the time that I was doing it, I was using "dedma", which was much more primitive, but also more resilient to changes. There's a bin2dedma helper somewhere to convert the "new" mmt trace format to what dedma can consume. FWIW I was given a file where the issue occurs very early on, but by then, I was already quite tired of doing this. I may be able to track it down, but right now, I'm not sure where it is. A final thought is that this happens on VP2 and VP3+ engines, which are fairly different from each other. This leads me to believe that we're missing a similar sort of thing on the two. I've always believed it was reference frame management-related, but could never quite figure it out. H264 streams may have up to 16 reference frames. Fun stuff. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] drm/nouveau/dispnv04: Grab/put runtime PM refs on DPMS on/off
On Wed, Aug 7, 2019 at 5:55 PM Daniel Vetter wrote:
>
> On Wed, Aug 07, 2019 at 05:33:00PM -0400, Lyude Paul wrote:
> > The code claims to grab a runtime PM ref when at least one CRTC is
> > active, but that's not actually the case as we grab a runtime PM ref
> > whenever a CRTC is enabled regardless of it's DPMS state. Meaning that
> > we can end up keeping the GPU awake when there are no screens enabled,
> > something we don't really want to do.
> >
> > Note that we fixed this same issue for nv50 a while ago in:
> >
> > commit e5d54f193572 ("drm/nouveau/drm/nouveau: Fix runtime PM leak in
> > nv50_disp_atomic_commit()")
> >
> > Since we're about to remove nouveau_drm->have_disp_power_ref in the next
> > commit, let's also simplify the RPM code here while we're at it: grab a
> > ref during a modeset, grab additional RPM refs for each CRTC enabled by
> > said modeset, and drop an RPM ref for each CRTC disabled by said
> > modeset. This allows us to keep the GPU awake whenever screens are
> > turned on, without needing to use nouveau_drm->have_disp_power_ref.
> >
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 18 --
> > 1 file changed, 4 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > index f22f01020625..08ad8e3b9cd2 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > @@ -183,6 +183,10 @@ nv_crtc_dpms(struct drm_crtc *crtc, int mode)
> > return;
> >
> > nv_crtc->last_dpms = mode;
> > + if (mode == DRM_MODE_DPMS_ON)
> > + pm_runtime_get_noresume(dev->dev);
> > + else
> > + pm_runtime_put_noidle(dev->dev);
>
> it's after we filter out duplicate operations, so that part looks good.
> But not all of nouveau's legacy helper crtc callbacks go throuh ->dpms I
> think: nv_crtc_disable doesn't, and crtc helpers use that in preference
> over ->dpms in some cases.
>
> I think the only way to actually hit that path is if you switch an active
> connector from an active CRTC to an inactive one. This implicitly disables
> the crtc (well, should, nv_crtc_disable doesn't seem to shut down hw), and
> I think would leak your runtime PM reference here. At least temporarily.
>
> No idea how to best fix that. Aside from "use atomic" :-)
Not sure if this is relevant to the discussion at hand, but I'd like
to point out that dispnv04 is for pre-nv50 things, which definitely
didn't support any kind of ACPI-based runtime suspend.
-ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] unstable refresh rate
That's OK - nouveau doesn't let you pick bit depth either (yet). It's all 8bpc - higher bpc mode support will come ... eventually. On Tue, Aug 6, 2019 at 5:25 PM James wrote: > > I think I may have updated the tv firmware between when it worked and > when it didn't. > I wonder it it has to do with bit depth. > I use lubuntu and it doesn't let me pick the bit depth so I don't know > what it using. > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] unstable refresh rate
Can you try something very simple - unplug the cable, and plug it back in, while the TV is on, and set to the HDMI input? That should ensure that the SCDC write can go through at modeset time. You can also force nouveau to avoid any modes that require scrambling by booting with nouveau.hdmimhz=340. Cheers, -ilia On Tue, Aug 6, 2019 at 1:15 PM James wrote: > > I was going to buy a new cable and I came across this description: > >Category 2 Certified HDMI wire supports resolutions up to 4Kx2K (UHD) > @30 Hz > > https://www.cnet.com/how-to/what-is-hdmi-2-0b/ > > HDMI versions compared > > HDMI Version Max Resolution Max 4K Frame rate HDCP 2.2HDR > > WCG Hybrid Log GammaDynamic Metadata > > 1.4 4K 30HzNo No No No No > > 2.0 4K 60HzYes No No No No > > 2.0a 4K 60HzYes Yes Yes No No > > 2.0b 4K 60HzYes Yes Yes Yes No > > 2.1 10K 120Hz Yes Yes Yes Yes Yes > > "Category 2" implies HDMI 2 but the "Max 4K Frame rate" of 30Hz says it > is HDMI-1.4. > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] unstable refresh rate
Hi James, I semi-recently added support for HDMI 2.0 (in 4.20+, so you're good), which is why you got 60Hz in the first place. In order for the high rates to work, something called "scrambling" must be enabled. This is done by 2-party agreement between the sink and the source. The sink will inform the source that it's about to use scrambling (by writing to the SCDC register on the display over i2c). In my personal experiments, on a LG C6 series TV, I found that while EDID works while the TV is off, the SCDC write does not. So you can actually "turn on" the display on the computer while the TV itself is off, and the scrambling setting will not have been propagated. Then when you turn the TV on, it doesn't work. In order to remedy this, you need to disable the display linux-side, and re-enable it. The indicator for this sort of issue would be something about SCDC reads/writes failing in dmesg -- do you see anything of the sort? (Something like "Failure to write SCDC_TMDS_CONFIG") If not, it's probably something else. But this seems like a likely candidate. On Tue, Aug 6, 2019 at 12:14 PM James wrote: > > I have a Gigabyte GeForce 1050 connected by DVI to a monitor (1920x1200 > resolution @ 59.9502 Hz) and a TV via HDMI (3840x2160 @30 Hz). > The problem is the TV used to work at 59.9685 Hz but then it started > showing "No signal" on the TV. > I was changing settings trying to get it to work again and I happened to > change it to 30Hz and it worked. > The specs are here: > https://www.gigabyte.com/Graphics-Card/GV-N1050OC-2GD/sp#sp > >Digital max resolution: 7680x4320 > I should be ok resolution wise. > Could it be a poor cable? > kernel: 5.0.0-23-generic > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Video Hardware Decoding: Jittery Rectangles on Nvidia GT218 NVA8 VP4.
On Mon, Jul 29, 2019 at 7:29 AM Solerman Kaplon wrote: > > Às 14:46 de 27/07/2019, Ilia Mirkin escreveu: > > On Sat, Jul 27, 2019 at 7:37 AM Ralph Corderoy > > wrote: > >> The video plays, CPU load is less (my aim), but there's ‘tearing’ of the > >> picture as if small rectangles that are updates are appearing in the > >> wrong location, off by a little. If I step through the frames with > >> mpv's ‘.’ and ‘,’ then I've found a pattern: one frame's picture is > >> good, followed by N bad ones where N is 3 or 7, i.e. every 4th or 8th > >> frame is okay. Don't know if that's a clue or helps someone here > >> recognise a known problem. > > >> Unfortunately I've never tracked down the cause for this. > >> https://nouveau.freedesktop.org/wiki/VideoAcceleration/ - see note #4. > >> > >> I have, over time, collected some sample videos where this happens in > >> the first few frames. The plan was to do mmt traces of the blob > >> driver, and figure out what it was doing differently. > > > > I don't really know anything about hw coding, but looking from the outside, it > seems some kind of ring buffer with exact 3 frames maybe intended to work > kinda > like using tripple buffering? I know for once that nvidia works better using > tripple buffering from what I've read from the kwin threads. The actual decoded images are wrong here -- triple buffering normally refers to how many (image) buffers you hold in the display queue. The deeper the queue, the more you're isolated from render timing. However in this case, the images themselves are bad out of the decoding logic. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Video Hardware Decoding: Jittery Rectangles on Nvidia GT218 NVA8 VP4.
On Sat, Jul 27, 2019 at 7:37 AM Ralph Corderoy wrote: > The video plays, CPU load is less (my aim), but there's ‘tearing’ of the > picture as if small rectangles that are updates are appearing in the > wrong location, off by a little. If I step through the frames with > mpv's ‘.’ and ‘,’ then I've found a pattern: one frame's picture is > good, followed by N bad ones where N is 3 or 7, i.e. every 4th or 8th > frame is okay. Don't know if that's a clue or helps someone here > recognise a known problem. > > I know X well, but Mesa, etc., below it are unknown to me, even to the > extent of knowing quite how all the bits fit together. I'd appreciate a > pointer or two as to how to tackle the problem, even if it's a ‘You've > come to the wrong place, go over there’. :-) Unfortunately I've never tracked down the cause for this. https://nouveau.freedesktop.org/wiki/VideoAcceleration/ - see note #4. I have, over time, collected some sample videos where this happens in the first few frames. The plan was to do mmt traces of the blob driver, and figure out what it was doing differently. If this is something you're interested in, I'd be happy to provide some guidance. However my past efforts to work this out were fruitless. Hopefully it's just something dumb we're doing in reference frame management, or a missing bit in the info structures, or something else entirely since I've scoured quite heavily for those two. If you'd like to dedicate some of your time to working this out, you can join us at #nouveau on freenode. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Questions on Maxwell 2nd Gen Compute Kernels/Shaders
On Mon, Jul 15, 2019 at 2:34 PM Fernando Sahmkow wrote: > > So we have been busy implementing the compute engine lately but we have > discovered a few issues with Compute Shaders. I hope you guys can answer some > questions. > > 1st How do I determine the size of Compute Shaders/Kernel Local Memory ? In > Pipeline shaders the size is included in the header but Compute Kernels don't > have a header, so how do I determine how much local memory it uses? In case I > can't is there a limit? From the header :) https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nve4_compute.h https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nve4_compute.c#n775 You may also find this interesting: https://nvidia.github.io/open-gpu-doc/classes/compute/ These docs appeared well after we had already RE'd, I don't think we ever went back to check if we'd missed anything substantial. > > 2nd I backtrack directions for LDG from the constbuffer that stores them. I > then use this directions then to compute the adress in my emulated SSBO. For > fragment, geometry and vertex shaders I got no problems with this directions. > For compute shaders the directions seem to be invalid, I imagine there's a > base adress that's added to this directions. Where can I obtain that base > adress? I don't think so. Can you show me an instruction stream that suggests this? I suspect you're misreading the code. Should work the same way as everywhere, except there are only 8 constbufs total, and so sometimes the actual constbuf data is also retrieved with LDG. > > 3rd SUATOM instraction CAS is similar to CompareAndSwap except it may add 1 > or 2 to the data register on store. How do I know when it adds 1 or 2? Uhm... huh? CAS = compare and swap. The argument order is different than the one in the API, as I recall, but there's no funny addition that I'm aware of. Now, there is a IADD.PO mode (PO = plus one), which corresponds to both arguments' neg bits being set, but that's the only such weirdness I'm aware of. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 2/4] gpio: fail if gpu external power is missing
Please add a config override to skip this, since we'll invariably get
it wrong for some setup, and should be able to provide users with
workarounds while the issue is being worked out.
On Mon, Jul 15, 2019 at 5:43 AM Mark Menzynski wrote:
>
> Currently, nouveau doesn't check if GPU is missing power. This
> patch makes nouveau fail when this happens on latest GPUs.
>
> It checks GPIO function 121 (External Power Emergency), which
> should detect power problems on GPU initialization.
>
> Tested on TU104, GP106 and GF100.
>
> Signed-off-by: Mark Menzynski
> ---
> drm/nouveau/include/nvkm/subdev/bios/gpio.h | 1 +
> drm/nouveau/nvkm/subdev/gpio/base.c | 23 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drm/nouveau/include/nvkm/subdev/bios/gpio.h
> b/drm/nouveau/include/nvkm/subdev/bios/gpio.h
> index 2f40935f..a70ec9e8 100644
> --- a/drm/nouveau/include/nvkm/subdev/bios/gpio.h
> +++ b/drm/nouveau/include/nvkm/subdev/bios/gpio.h
> @@ -7,6 +7,7 @@ enum dcb_gpio_func_name {
> DCB_GPIO_TVDAC0 = 0x0c,
> DCB_GPIO_TVDAC1 = 0x2d,
> DCB_GPIO_FAN_SENSE = 0x3d,
> + DCB_GPIO_EXT_POWER_LOW = 0x79,
> DCB_GPIO_LOGO_LED_PWM = 0x84,
> DCB_GPIO_UNUSED = 0xff,
> DCB_GPIO_VID0 = 0x04,
> diff --git a/drm/nouveau/nvkm/subdev/gpio/base.c
> b/drm/nouveau/nvkm/subdev/gpio/base.c
> index 1399d923..c4685807 100644
> --- a/drm/nouveau/nvkm/subdev/gpio/base.c
> +++ b/drm/nouveau/nvkm/subdev/gpio/base.c
> @@ -182,12 +182,35 @@ static const struct dmi_system_id gpio_reset_ids[] = {
> { }
> };
>
> +static enum dcb_gpio_func_name power_checks[] = {
> + DCB_GPIO_EXT_POWER_LOW,
> +};
> +
> static int
> nvkm_gpio_init(struct nvkm_subdev *subdev)
> {
> struct nvkm_gpio *gpio = nvkm_gpio(subdev);
> + struct dcb_gpio_func func;
> + int ret;
> + int i;
> +
> if (dmi_check_system(gpio_reset_ids))
> nvkm_gpio_reset(gpio, DCB_GPIO_UNUSED);
> +
> + for (i = 0; i < ARRAY_SIZE(power_checks); ++i) {
> + ret = nvkm_gpio_find(gpio, 0, power_checks[i],
> DCB_GPIO_UNUSED,
> +&func);
> + if (ret)
> + continue;
> +
> + ret = nvkm_gpio_get(gpio, 0, func.func, func.line);
> + if (ret) {
> + nvkm_error(&gpio->subdev,
> + "not enough power, check GPU power
> cable\n");
> + return -EINVAL;
> + }
> + }
> +
> return 0;
> }
>
> --
> 2.21.0
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Questions on Falcon Command Processor
I believe that NVDec is similar to the MSDEC engines (BSP, VP, and PPP) on Kepler GPUs. You can see the details of the various bits being submitted here: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nouveau_vp3_video.h https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c and some related code. I haven't investigated the precise details of NVDec yet, but rumors suggest it should be similar, even though it's a single engine now rather than many. You'll have to do some sniffing. Cheers, -ilia On Tue, Jul 9, 2019 at 4:36 PM Fernando Sahmkow wrote: > > So now I'm to looking to implement NVDec and as far as I know the game > submits a series of commands to the service. This commands are processed by > Falcon and then it does its magic. Do you guys got any RE on Falcon commands > and how they execute different workloads ? > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 20/22] mm: move hmm_vma_fault to nouveau
On Wed, Jul 3, 2019 at 1:49 PM Ralph Campbell wrote: > On 6/30/19 11:20 PM, Christoph Hellwig wrote: > > hmm_vma_fault is marked as a legacy API to get rid of, but quite suites > > the current nouvea flow. Move it to the only user in preparation for > > I didn't quite parse the phrase "quite suites the current nouvea flow." > s/nouvea/nouveau/ As long as you're fixing typos, suites -> suits. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Question on Conditional Rendering Maxwell/Pascal
Yeah, this is a little confusing. It's important to remember how queries work in the first place, which informs how conditional rendering works. There are two kind of queries (QUERY_ADDRESS_HIGH & co) -- "short" and "long". A "short" query value is a single 32-bit value, presumably the value of the thing being queried. Not all queries are available in this mode, but some are. This mode is useless for conditional rendering. The long mode is a a value, and, iirc, a timestamp value. The value itself can be 2x 32-bit values too, while the timestamp is basically useless (except for the "timestamp" query). Now, conditional rendering is basically only used with GL_SAMPLES_PASSED and GL_ANY_SAMPLES_PASSED (and stream-overflow-predicate). For both of these, you do a long-mode query, which dumps the following 32-bit values into the 128-bit record: seqno (QUERY_ADDRESS_SEQUENCE), count, tslo, tshi Conditional rendering expects a pair of such 128-bit records to follow one another, and, I believe, performs the indicated operation on the first 64-bit value. We pre-initialize the pair of such values here: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c#n151 hq->data[0] = hq->sequence; /* initialize sequence */ hq->data[1] = 1; /* initial render condition = true */ hq->data[4] = hq->sequence + 1; /* for comparison COND_MODE */ hq->data[5] = 0; And we make sure that the EndConditionalRender data query ends up in data[0:3], while the BeginConditionalRender data ends up in data[4:7]. And so the values RES_NON_ZERO means "data[0:1] != 0", EQUAL means "data[0:1] == data[4:5]", NOT_EQUAL -- I'll let you guess. And so the render condition in the common case is NOT_EQUAL, since we only want to render when there is a difference in the count of samples passed. (This is a context-level counter, whose enablement is controlled by SAMPLECNT_ENABLE (and COUNTER_RESET to clear it). As for what happens when there is no draw, only the draw itself is skipped. All value updates should happen as normal. Hope this helps, -ilia On Sun, Jun 30, 2019 at 6:55 PM Fernando Sahmkow wrote: > > So we are currently doing tests and complying with them in our Emulator. > Currently the conditional rendering test does not pass (no wonder we not even > implement it). I've been looking at the current documentation > https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L796 > So far I don't understand how the cond address is used and to what it's > compared. > https://github.com/envytools/envytools/blob/0d91b8bcef3ceb47ff0b114025d301edb790d472/rnndb/g80_defs.xml#L61 > > It says it uses 2 queries, how do I know which query it's talking off and > what it's the comparison that should be done. > > Also, does failing conditional rendering makes registers not write into the > engine or just drawcalls/claers are ignored? > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NOUVEAU_LEGACY_CTX_SUPPORT Fan Speed
Hi Mar, Could you file a bug (bugs.freedesktop.org under xorg -> Driver/nouveau) with a summary of this info (i.e. a problem statement, that reverting the commit in question fixes it, the lspci output) and additionally, your VBIOS. You can obtain this with nouveau loaded by doing cp /sys/kernel/debug/dri/0/vbios.rom /tmp This will help centralize all the info. Thanks, -ilia On Sun, Jun 23, 2019 at 12:34 AM Mar Mel wrote: > Sure: > > $ lspci -nn -d 10de: > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT200 > [GeForce GTX 260] [10de:05e2] (rev a1) > > > On Saturday, June 22, 2019, 2:19:31 PM EDT, Ilia Mirkin < > imir...@alum.mit.edu> wrote: > > > Mar - can you provide the output of > > lspci -nn -d 10de: > > On Sat, Jun 22, 2019 at 2:17 PM Lyude Paul wrote: > > Hi, is this actually an nv50 GPU, or some other model? I can try to take a > closer look at this > > On Sun, 2019-06-16 at 10:28 -0400, Ilia Mirkin wrote: > > I don't really see anything between v5.0..v5.1 which would account for > this. Could have been a subtle change to the i2c logic somewhere. The > fastest way to identify the problem would be to do a bisect on the kernel > to identify the commit that caused this. There are many guides for this > online. > > On Sat, Jun 15, 2019 at 12:17 PM Mar Mel wrote: > > Unfortunately, even with this change now reverted in kernel 5.1.10, the > fan speed issue persists. > > If someone could point me in the direction of a relevant commit(s) I'll > happily file a bug report. > > On Thursday, June 13, 2019, 11:19:25 AM EDT, Mar Mel > wrote: > > > As of kernel 5.1.9, on resume from suspend, my NV50 fan runs at full > speed. > > Not sure if it has to do with this new config option ( > NOUVEAU_LEGACY_CTX_SUPPORT)? > > This issue is not present using kernel 5.0.21. > > Years ago I filed a similar issue: > > 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50 > adt7475 on kernels 3.3.x+ > <https://bugs.freedesktop.org/show_bug.cgi?id=60704> > > Thanks. > > > 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50 a... > > <https://bugs.freedesktop.org/show_bug.cgi?id=60704> > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau > > ___ > > Nouveau mailing list > > Nouveau@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/nouveau > > -- > > Cheers, > Lyude Paul > > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NOUVEAU_LEGACY_CTX_SUPPORT Fan Speed
Mar - can you provide the output of lspci -nn -d 10de: On Sat, Jun 22, 2019 at 2:17 PM Lyude Paul wrote: > Hi, is this actually an nv50 GPU, or some other model? I can try to take a > closer look at this > > On Sun, 2019-06-16 at 10:28 -0400, Ilia Mirkin wrote: > > I don't really see anything between v5.0..v5.1 which would account for > this. Could have been a subtle change to the i2c logic somewhere. The > fastest way to identify the problem would be to do a bisect on the kernel > to identify the commit that caused this. There are many guides for this > online. > > On Sat, Jun 15, 2019 at 12:17 PM Mar Mel wrote: > > Unfortunately, even with this change now reverted in kernel 5.1.10, the > fan speed issue persists. > > If someone could point me in the direction of a relevant commit(s) I'll > happily file a bug report. > > On Thursday, June 13, 2019, 11:19:25 AM EDT, Mar Mel > wrote: > > > As of kernel 5.1.9, on resume from suspend, my NV50 fan runs at full > speed. > > Not sure if it has to do with this new config option ( > NOUVEAU_LEGACY_CTX_SUPPORT)? > > This issue is not present using kernel 5.0.21. > > Years ago I filed a similar issue: > > 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50 > adt7475 on kernels 3.3.x+ > <https://bugs.freedesktop.org/show_bug.cgi?id=60704> > > Thanks. > > > 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50 a... > > <https://bugs.freedesktop.org/show_bug.cgi?id=60704> > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau > > ___ > > Nouveau mailing list > > Nouveau@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/nouveau > > -- > > Cheers, > Lyude Paul > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau/kms/gf119-: allow both 256- and 1024-sized LUTs to be used
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Finally, experimental evidence suggests you can't mix sizes for degamma
and gamma. Disallow this as well.
Signed-off-by: Ilia Mirkin
---
Note that all the gv100+ changes are purely speculative.
Tested on a GK208 with 8- and 10-bpc formats (but still 8bpc output).
This is on top of the patches which I've sent in the past. You'll end up
with some conflicts, I suspect, but I can't rebase easily on your changes
since they're not in a linux tree.
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/head.c | 26 +
drivers/gpu/drm/nouveau/dispnv50/head.h | 10 +---
drivers/gpu/drm/nouveau/dispnv50/head507d.c | 10 +++-
drivers/gpu/drm/nouveau/dispnv50/head827d.c | 2 ++
drivers/gpu/drm/nouveau/dispnv50/head907d.c | 12 --
drivers/gpu/drm/nouveau/dispnv50/head917d.c | 2 ++
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 6 +++--
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 9 +++
drivers/gpu/drm/nouveau/dispnv50/lut.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c | 3 +--
15 files changed, 70 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/base907c.c
b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
index fd0c1d84730b..76db448205d2 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/base907c.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
@@ -76,9 +76,9 @@ base907c_xlut_set(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw)
}
static void
-base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw)
+base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw, int size)
{
- asyw->xlut.i.mode = 7;
+ asyw->xlut.i.mode = size == 1024 ? 4 : 7;
asyw->xlut.i.enable = 2;
asyw->xlut.i.load = head907d_olut_load;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv50/corec57d.c
b/drivers/gpu/drm/nouveau/dispnv50/corec57d.c
index b606d68cda10..700df4762b6d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/corec57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/corec57d.c
@@ -36,7 +36,7 @@ corec57d_init(struct nv50_core *core)
evo_data(push, 0x000f);
evo_data(push, 0x);
evo_mthd(push, 0x1010 + (i * 0x080), 1);
- evo_data(push, 0x00117fff);
+ evo_data(push, 0x00127fff);
}
evo_mthd(push, 0x0200, 1);
evo_data(push, 0x0001);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 8cac8b724b70..407c91bd09b9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -193,7 +193,23 @@ nv50_head_atomic_check_lut(struct nv50_head *head,
struct nv50_head_atom *asyh)
{
struct nv50_disp *disp = nv50_disp(head->base.base.dev);
+ struct drm_property_blob *ilut = asyh->state.degamma_lut;
struct drm_property_blob *olut = asyh->state.gamma_lut;
+ int ilut_size = ilut ? drm_color_lut_size(ilut) : 0;
+ int olut_size = olut ? drm_color_lut_size(olut) : 0;
+
+ if (!head->func->lut_chk(ilut_size)) {
+ DRM_DEBUG_KMS("Invalid DEGAMMA_LUT size: %d\n", ilut_size);
+ return -EINVAL;
+ }
+ if (!head->func->lut_chk(olut_size)) {
+ DRM_DEBUG_KMS("Invalid GAMMA_LUT size: %d\n", olut_size);
+ return -EINVAL;
+ }
+ if (ilut && olut && ilut_size != olut_size) {
+ DRM_DEBUG_KMS("DEGAMMA_LUT size (%d) must match GAMMA_LUT size
(%d)\n",
+ ilut_size, olut_size);
+ }
/* Determine whether core output LUT should be enabled. */
if (olut) {
@@ -217,7 +233,7 @@ nv50_head_atomic_check_lut(struct nv50_head *head,
asyh->olut.handle = disp->core->chan.vram.handle;
asyh->olut.buffer = !asyh->olut.buffer;
- head->func->olut(head, asyh);
+ head->func->olut(head, asyh, olut_size);
return 0;
}
@@ -491,12 +507,14 @@ nv50_head_create(struct drm_device *dev, int index)
drm_crtc_init_with_planes(dev, crtc, &wndw->plane, &curs->plane,
&nv50_head_func, "head-%d", head->base.index);
drm_crtc_helper_add(crtc, &nv50_head_help);
- drm_mode_crtc_set_gamma_size(crtc, 256);
+ drm_mode_crtc_set_gamma_size(crtc, head->func->lut_size)
Re: [Nouveau] Instable graphics with GeForce GT 730M, especially on external monitor
Sigh ... you're on wayland. xrandr is just showing you what's passed through via Xwayland, which is not the connector names. Let's try something else... grep . /sys/class/drm/card*-*/status Should give you the status of each connector. Is it the DP-* ones that are connected, or are e.g. VGA-1 or DVI-D-1/etc connected? -ilia On Wed, Jun 19, 2019 at 2:03 AM Harald Harders wrote: > > When the monitor is connected via DVI, the xrandr output is as follows: > > harders@lose:~> xrandr > Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192 > XWAYLAND0 connected 1920x1080+1920+0 (normal left inverted right x axis y > axis) 310mm x 170mm >1920x1080 59.96*+ > XWAYLAND1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) > 520mm x 320mm >1920x1200 59.88*+ > > or verbose: > > harders@lose:~> xrandr --verbose > Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192 > XWAYLAND0 connected 1920x1080+1920+0 (0x24) normal (normal left inverted > right x axis y axis) 310mm x 170mm > Identifier: 0x21 > Timestamp: 41572 > Subpixel: unknown > Gamma: 1.0:1.0:1.0 > Brightness: 0.0 > Clones: > CRTC: 0 > CRTCs: 0 > Transform: 1.00 0.00 0.00 > 0.00 1.00 0.00 > 0.00 0.00 1.00 >filter: > non-desktop: 0 > supported: 0, 1 > 1920x1080 (0x24) 173.000MHz -HSync +VSync *current +preferred > h: width 1920 start 2048 end 2248 total 2576 skew0 clock > 67.16KHz > v: height 1080 start 1083 end 1088 total 1120 clock 59.96Hz > XWAYLAND1 connected 1920x1200+0+0 (0x25) normal (normal left inverted right x > axis y axis) 520mm x 320mm > Identifier: 0x23 > Timestamp: 41572 > Subpixel: unknown > Gamma: 1.0:1.0:1.0 > Brightness: 0.0 > Clones: > CRTC: 1 > CRTCs: 1 > Transform: 1.00 0.00 0.00 > 0.00 1.00 0.00 > 0.00 0.00 1.00 >filter: > non-desktop: 0 > supported: 0, 1 > 1920x1200 (0x25) 193.250MHz -HSync +VSync *current +preferred > h: width 1920 start 2056 end 2256 total 2592 skew0 clock > 74.56KHz > v: height 1200 start 1203 end 1209 total 1245 clock 59.88Hz > > When switching to VGA cable, the only changes are in the gamma, brightness, > and Identifier values. I don't find anything which refers to DP or a port. > What else can I do to narrow it down? > -- > Harald Harders > harald.hard...@gmx.de > > > Gesendet: Dienstag, 18. Juni 2019 um 22:30 Uhr > Von: "Ilia Mirkin" > An: "Harald Harders" > Cc: nouveau > Betreff: Re: [Nouveau] Instable graphics with GeForce GT 730M, especially on > external monitor > What's the connector name when you plug in via, say, DVI? Is it "DP-1" > or is it "DVI-D-1" or whatever? You should be able to see the name in > 'xrandr'. Unfortunately I don't know how the T440p is wired, there are > a few ways it could go. In some cases, even the "VGA" port is secretly > a DP -> VGA active adapter inside the laptop. > > Basically I'm trying to rule DisplayPort as a source of potential issues. > > -ilia > > On Tue, Jun 18, 2019 at 4:12 PM Harald Harders wrote: > > > > Hi Ilia, > > > > First I had upgraded from OpenSUSE 13.2 (where it worked) to OpenSUSE Leap > > 15.1. After having the same issue I have done a clean new install. The new > > kernel version is 4.12.14, as you suspected. In OpenSUSE, I suspect it was > > version 3.16.7. Unfortunately, I cannot find out anymore which nouveau > > version I have used before. I have a file backup of the old installation. > > Can I find out which nouveau version I had before? > > > > During all my attempts, I have also installed Ubuntu 18.04.2 with the same > > strange behaviour. I guess this was the 4.18 kernel version? > > Do you know which distrubtion already uses a 5.0 kernel? I will try a live > > system, then. > > > > I have a docking station with 4 monitor ports: VGA, DVI, HDMI, Displayport. > > And my laptop has VGA and Mini-Displayport. My monitor (Fujitsu P24W-7 LED) > > has VGA, DVI, HDMI, and Displayport. > > I have tried DVI->DVI and DisplayPort->HDMI cable on the docking station (I > > don't hav. In one of my attempts, I have
Re: [Nouveau] nouveau: DRM: GPU lockup - switching to software fbcon
On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky wrote: > > On (06/19/19 01:20), Ilia Mirkin wrote: > > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky > > wrote: > > > > > > On (06/14/19 11:50), Sergey Senozhatsky wrote: > > > > dmesg > > > > > > > > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon > > > > nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > > > > nouveau :01:00.0: fifo: runlist 0: scheduled for recovery > > > > nouveau :01:00.0: fifo: channel 5: killed > > > > nouveau :01:00.0: fifo: engine 6: scheduled for recovery > > > > nouveau :01:00.0: fifo: engine 0: scheduled for recovery > > > > nouveau :01:00.0: firefox[476]: channel 5 killed! > > > > nouveau :01:00.0: firefox[476]: failed to idle channel 5 > > > > [firefox[476]] > > > > > > > > It lockups several times a day. Twice in just one hour today. > > > > Can we fix this? > > > > > > Unusable > > > > Are you using a GTX 660 by any chance? You've provided rather minimal > > system info. > > 01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] > (rev a1) Quite literally the same GPU I have plugged in... 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208B [GeForce GT 730] [10de:1287] (rev a1) Works great here! Only other thing I can think of is that I avoid applications with the letters "G" and "K" in their names, and I'm using xf86-video-nouveau ddx, whereas you might be using the "modeset" ddx with glamor. If all else fails, just remove nouveau_dri.so and/or boot with nouveau.noaccel=1 -- should be perfect. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau: DRM: GPU lockup - switching to software fbcon
On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky wrote: > > On (06/14/19 11:50), Sergey Senozhatsky wrote: > > dmesg > > > > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon > > nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] > > nouveau :01:00.0: fifo: runlist 0: scheduled for recovery > > nouveau :01:00.0: fifo: channel 5: killed > > nouveau :01:00.0: fifo: engine 6: scheduled for recovery > > nouveau :01:00.0: fifo: engine 0: scheduled for recovery > > nouveau :01:00.0: firefox[476]: channel 5 killed! > > nouveau :01:00.0: firefox[476]: failed to idle channel 5 [firefox[476]] > > > > It lockups several times a day. Twice in just one hour today. > > Can we fix this? > > Unusable Are you using a GTX 660 by any chance? You've provided rather minimal system info. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Instable graphics with GeForce GT 730M, especially on external monitor
What's the connector name when you plug in via, say, DVI? Is it "DP-1" or is it "DVI-D-1" or whatever? You should be able to see the name in 'xrandr'. Unfortunately I don't know how the T440p is wired, there are a few ways it could go. In some cases, even the "VGA" port is secretly a DP -> VGA active adapter inside the laptop. Basically I'm trying to rule DisplayPort as a source of potential issues. -ilia On Tue, Jun 18, 2019 at 4:12 PM Harald Harders wrote: > > Hi Ilia, > > First I had upgraded from OpenSUSE 13.2 (where it worked) to OpenSUSE Leap > 15.1. After having the same issue I have done a clean new install. The new > kernel version is 4.12.14, as you suspected. In OpenSUSE, I suspect it was > version 3.16.7. Unfortunately, I cannot find out anymore which nouveau > version I have used before. I have a file backup of the old installation. Can > I find out which nouveau version I had before? > > During all my attempts, I have also installed Ubuntu 18.04.2 with the same > strange behaviour. I guess this was the 4.18 kernel version? > Do you know which distrubtion already uses a 5.0 kernel? I will try a live > system, then. > > I have a docking station with 4 monitor ports: VGA, DVI, HDMI, Displayport. > And my laptop has VGA and Mini-Displayport. My monitor (Fujitsu P24W-7 LED) > has VGA, DVI, HDMI, and Displayport. > I have tried DVI->DVI and DisplayPort->HDMI cable on the docking station (I > don't hav. In one of my attempts, I have connected the screen via analog VGA > cable directly to the computer. The same effect resulted. Thus, I believe the > docking station and digital connection to the monitor are not part of the > problem. > > Best regards > Harald > > PS: I guess sending to the mailing list and omitting your personal mail > address is correct, right? > > > Gesendet: Dienstag, 18. Juni 2019 um 21:36 Uhr > Von: "Ilia Mirkin" > An: "Harald Harders" > Cc: nouveau > Betreff: Re: [Nouveau] Instable graphics with GeForce GT 730M, especially on > external monitor > Which kernel did you update from and to? Also, 4.12 is fairly old - > can you try like a live usb image of some distro with e.g. a 5.0 > kernel or something? > > How do you connect the external screen? Is it like a DP port with an > optional dock with a variety of active DP adapters? Or is there a DP++ > port that you're plugging a DP <-> HDMI passive adapter into? > > On Tue, Jun 18, 2019 at 3:28 PM Harald Harders wrote: > > > > Dear all, > > > > I have recently updated my Lenovo T440p with a dual graphics card (Intel > > Core + GeForce GT 730M) to OpenSUSE Leap 15.1. Since then, the external > > screen (connected either via VGA, DVI, HDMI, or DisplayPort) has a > > vertically stretched output which jumps horizontally in high frequency. > > Whenever touching any settings for the built in display (e.g. by > > gnome-control-center), also this screen starts incorrect display. > > Sometimes, however, also the external screen works as expected. > > > > Installed driver version is (only 2D installed): > > xf86-video-nouveau: 1.0.15-lp151.4.1 > > libvdpau_nouveau: 18.3.2-lp151.22.4 > > libdrm_nouveau2: 2.4.97-lp151.1.1 > > > > I have followed your instructions on the TroubleShooting page, No signs for > > NVIDIA drivers running, everything appears to be okay. Minimal xorg.conf > > did not work, screenshots are okay.Unfortunately, I failed in installing > > the most recent nouveau version (neither > > /lib/modules/4.12.14-lp151.28.4-default/source nor > > /lib/modules/4.12.14-lp151.28.4-default/build are present on my computer > > even though I have installed the Kernel sources). The installed version is > > still quite new, isn't it? > > > > I suspect that I might have the issue you describe under "Blank monitor, > > flicker, snow, or other random live image corruption". I would like to make > > sure, however. And since you warn with regards to potential permanent > > damage, I would like to make sure, first. > > Can you confirm that it should be this issue? Or are there any other things > > I should try first? > > > > Best regards > > Harald > > > > > > > > > > > > > > > > > > > > lose:/home/harders/download/nouveau/drm # lspci | grep -i vga > > 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor > > Integrated Graphics Controller (rev 06) > > 02:00.0 VGA compatible controller: NVIDIA Corporation GK208M [GeForce GT > > 730M] (rev a1) > > > > ___ > > Nouveau mailing list > > Nouveau@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/nouveau > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Instable graphics with GeForce GT 730M, especially on external monitor
Which kernel did you update from and to? Also, 4.12 is fairly old - can you try like a live usb image of some distro with e.g. a 5.0 kernel or something? How do you connect the external screen? Is it like a DP port with an optional dock with a variety of active DP adapters? Or is there a DP++ port that you're plugging a DP <-> HDMI passive adapter into? On Tue, Jun 18, 2019 at 3:28 PM Harald Harders wrote: > > Dear all, > > I have recently updated my Lenovo T440p with a dual graphics card (Intel Core > + GeForce GT 730M) to OpenSUSE Leap 15.1. Since then, the external screen > (connected either via VGA, DVI, HDMI, or DisplayPort) has a vertically > stretched output which jumps horizontally in high frequency. Whenever > touching any settings for the built in display (e.g. by > gnome-control-center), also this screen starts incorrect display. Sometimes, > however, also the external screen works as expected. > > Installed driver version is (only 2D installed): > xf86-video-nouveau: 1.0.15-lp151.4.1 > libvdpau_nouveau: 18.3.2-lp151.22.4 > libdrm_nouveau2: 2.4.97-lp151.1.1 > > I have followed your instructions on the TroubleShooting page, No signs for > NVIDIA drivers running, everything appears to be okay. Minimal xorg.conf did > not work, screenshots are okay.Unfortunately, I failed in installing the most > recent nouveau version (neither > /lib/modules/4.12.14-lp151.28.4-default/source nor > /lib/modules/4.12.14-lp151.28.4-default/build are present on my computer even > though I have installed the Kernel sources). The installed version is still > quite new, isn't it? > > I suspect that I might have the issue you describe under "Blank monitor, > flicker, snow, or other random live image corruption". I would like to make > sure, however. And since you warn with regards to potential permanent damage, > I would like to make sure, first. > Can you confirm that it should be this issue? Or are there any other things I > should try first? > > Best regards > Harald > > > > > > > > > > lose:/home/harders/download/nouveau/drm # lspci | grep -i vga > 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor > Integrated Graphics Controller (rev 06) > 02:00.0 VGA compatible controller: NVIDIA Corporation GK208M [GeForce GT > 730M] (rev a1) > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
