search for: nvaf

https://bugs.freedesktop.org/show_bug.cgi?id=77574 Priority: medium Bug ID: 77574 Assignee: nouveau at lists.freedesktop.org Summary: Minor screen corruption on NVAF card QA Contact: xorg-team at lists.x.org Severity: minor Classification: Unclassified OS: Linux (All) Reporter: adonai at xaker.ru Hardware: x86-64 (AMD64) Status: NEW Version: 7.7 (2011) Component: Driver/no...

Dear All, After recently taking a little dive into the NVAC clock tree, I was wondering what that net would look like on cards I expect to be similar. In this case I'm looking for MMIOtraces of NVAA and NVAF, which is marketed as the 8x00 mGPU, 9x00 mGPU, 320M, ION and/or some nForce IGP. If there is anyone who could provide me with an MMIO trace for any of these cards that would be greatly appreciated. If you need help in the process, please contact me by e-mail or on IRC. Many thanks in advance....

https://bugs.freedesktop.org/show_bug.cgi?id=56748 Priority: medium Bug ID: 56748 Assignee: nouveau at lists.freedesktop.org Summary: [NVAF] Graphic Elements Displayed Partially QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: nihilhill at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: uns...

https://bugs.freedesktop.org/show_bug.cgi?id=60150 Priority: medium Bug ID: 60150 Assignee: nouveau at lists.freedesktop.org Summary: [NVAF] Garbled Screen QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: nihilhill at gmail.com Hardware: Other Status: NEW Version: unspecified Component: Driver/no...

https://bugs.freedesktop.org/show_bug.cgi?id=83957 Priority: medium Bug ID: 83957 Assignee: nouveau at lists.freedesktop.org Summary: [NV50 - NVAF][MCP89] Major screen corruption and X crash soon after log in QA Contact: xorg-team at lists.x.org Severity: critical Classification: Unclassified OS: Linux (All) Reporter: qc.loic at gmail.com Hardware: x86-64 (AMD64)...

https://bugs.freedesktop.org/show_bug.cgi?id=44849 Bug #: 44849 Summary: nouveau loads scrambled garbage Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component:

Hi guys, With a GeForce 320M GPU running linux 3.13.2 and Xorg 1.15.0, I'm seeing significant graphical corruption and later unrecoverable GPU lockup, accompanied by thousands of ILLEGAL_MTHD or related kernel messages [1]. I see similar issues on 3.12 also. Is there any debugging or testing I can do to help diagnose this? Many thanks, Daniel --- [1] http://quora.org/nouveau-dmesg.txt

...lls back to M2MF, and so does the DDX, and I don't see any usage in mesa, so even _if_ it's incorrectly disabled, I doubt this would be your issue.) Another thing that's new in 3.13 is MSI -- you can disable it with nouveau.config=NvMSI=0. There's only one currently-open bug about NVAF: https://bugs.freedesktop.org/show_bug.cgi?id=60150 -- unfortunately the bug filer wasn't very specific about the issues. But it might be worth trying an ancient kernel (e.g. pre-3.7 -- there was a big rewrite in 3.7, or even one of those 3.2-based franken-kernels that distros maintained.) I su...

...DDX, > and I don't see any usage in mesa, so even _if_ it's incorrectly > disabled, I doubt this would be your issue.) > > Another thing that's new in 3.13 is MSI -- you can disable it with > nouveau.config=NvMSI=0. > > There's only one currently-open bug about NVAF: > https://bugs.freedesktop.org/show_bug.cgi?id=60150 -- unfortunately > the bug filer wasn't very specific about the issues. But it might be > worth trying an ancient kernel (e.g. pre-3.7 -- there was a big > rewrite in 3.7, or even one of those 3.2-based franken-kernels that >...

...=============== > > [ 2.654061] fb: switching to nouveaufb from simple > [ 2.666836] nouveau 0000:04:00.0: enabling device (0006 -> 0007) > [ 2.667790] nouveau [ DEVICE][0000:04:00.0] BOOT0 : 0x0af000a2 > [ 2.667793] nouveau [ DEVICE][0000:04:00.0] Chipset: MCP89 (NVAF) > [ 2.667795] nouveau [ DEVICE][0000:04:00.0] Family : NV50 > [ 2.667837] nouveau [ VBIOS][0000:04:00.0] checking PRAMIN for > image... > [ 2.730295] nouveau [ VBIOS][0000:04:00.0] ... appears to be valid > [ 2.730298] nouveau [ VBIOS][0000:04:00.0] using imag...

Hi, I have an (recently) unused mid-2010 MacBook that I could give to anyone interested to play with : the included GeForce 320M (NVAF (MCP89)) seems to be rare (only on a few Apple hardware). I always wonder how you guys/women managed to make this weird GPU mostly working: many thanks for your work, you really deserve it ! Currently (last usage was with Ubuntu 15.10), the support with Nouveau can still be improved (but is alrea...

...--------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #35 from Ilia Mirkin <imirkin at alum.mit.edu> --- Closing as fixed per the comments. There are several NVAF-related bugs currently open, feel free to subscribe to them. (I've requested retests on them, although haven't heard back yet.) -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <htt...

Here's a quick-but-I-guess-tidy-fix for faulty behaviour someone reported in NVAF. I'm just not sure if the check for nvaa/nvac should still be in nv50_pm_clocks_pre... I believe this is wrong as they can reclock perfectly well (except the non-existing memory). Anyone has a definite answer to that?

...; diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile > index 3548fcd..d9fe3e6 100644 > --- a/drivers/gpu/drm/nouveau/Makefile > +++ b/drivers/gpu/drm/nouveau/Makefile > @@ -100,6 +100,7 @@ nouveau-y += core/subdev/fb/nvaa.o > nouveau-y += core/subdev/fb/nvaf.o > nouveau-y += core/subdev/fb/nvc0.o > nouveau-y += core/subdev/fb/nve0.o > +nouveau-y += core/subdev/fb/nvea.o > nouveau-y += core/subdev/fb/ramnv04.o > nouveau-y += core/subdev/fb/ramnv10.o > nouveau-y += core/subdev/fb/ramnv1a.o > @@ -114,6 +115,7 @@ nouveau-y += core...

...| grep nouveau: ====================== [ 2.654061] fb: switching to nouveaufb from simple [ 2.666836] nouveau 0000:04:00.0: enabling device (0006 -> 0007) [ 2.667790] nouveau [ DEVICE][0000:04:00.0] BOOT0 : 0x0af000a2 [ 2.667793] nouveau [ DEVICE][0000:04:00.0] Chipset: MCP89 (NVAF) [ 2.667795] nouveau [ DEVICE][0000:04:00.0] Family : NV50 [ 2.667837] nouveau [ VBIOS][0000:04:00.0] checking PRAMIN for image... [ 2.730295] nouveau [ VBIOS][0000:04:00.0] ... appears to be valid [ 2.730298] nouveau [ VBIOS][0000:04:00.0] using image from PRAMIN [ 2.7303...

...nouveau-y += core/subdev/clock/pllnv04.o nouveau-y += core/subdev/clock/pllnva3.o nouveau-y += core/subdev/devinit/base.o @@ -76,7 +76,7 @@ nouveau-y += core/subdev/devinit/nv84.o nouveau-y += core/subdev/devinit/nv98.o nouveau-y += core/subdev/devinit/nva3.o nouveau-y += core/subdev/devinit/nvaf.o -nouveau-y += core/subdev/devinit/nvc0.o +nouveau-$(CONFIG_DRM_NOUVEAU_NVC0) += core/subdev/devinit/nvc0.o nouveau-y += core/subdev/fb/base.o nouveau-y += core/subdev/fb/nv04.o nouveau-y += core/subdev/fb/nv10.o @@ -98,8 +98,8 @@ nouveau-y += core/subdev/fb/nv84.o nouveau-y += core/subdev/fb/...

.../core/subdev/fb/ramnvea.c diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile index 3548fcd..d9fe3e6 100644 --- a/drivers/gpu/drm/nouveau/Makefile +++ b/drivers/gpu/drm/nouveau/Makefile @@ -100,6 +100,7 @@ nouveau-y += core/subdev/fb/nvaa.o nouveau-y += core/subdev/fb/nvaf.o nouveau-y += core/subdev/fb/nvc0.o nouveau-y += core/subdev/fb/nve0.o +nouveau-y += core/subdev/fb/nvea.o nouveau-y += core/subdev/fb/ramnv04.o nouveau-y += core/subdev/fb/ramnv10.o nouveau-y += core/subdev/fb/ramnv1a.o @@ -114,6 +115,7 @@ nouveau-y += core/subdev/fb/ramnva3.o nouveau-y +=...

...ey Alex, > > Thanks. I have a couple of questions and remarks, but really, those should > be treated as discussion points rather than anything else. Besides some > inline comments, I was curious whether it is not necessary to pause PFIFO > and the engines like done with at least NVA3-NVAF? Or is the transition > smooth enough? AFAIK there is no need to pause the engines during a clock transition, as the ChromeOS driver does not do it. > > op 10-07-14 09:34, Alexandre Courbot schreef: > >> Add support for reclocking on GK20A, using a statically-defined pstates &gt...

...bdev/devinit/nv10.o -nouveau-y += core/subdev/devinit/nv1a.o -nouveau-y += core/subdev/devinit/nv20.o -nouveau-y += core/subdev/devinit/nv50.o -nouveau-y += core/subdev/devinit/nv84.o -nouveau-y += core/subdev/devinit/nv98.o -nouveau-y += core/subdev/devinit/nva3.o -nouveau-y += core/subdev/devinit/nvaf.o -nouveau-y += core/subdev/devinit/nvc0.o +nouveau-$(CONFIG_DRM_NOUVEAU_NV04) += core/subdev/devinit/nv04.o +nouveau-$(CONFIG_DRM_NOUVEAU_NV04) += core/subdev/devinit/nv05.o +nouveau-$(CONFIG_DRM_NOUVEAU_NV04) += core/subdev/devinit/nv10.o +nouveau-$(CONFIG_DRM_NOUVEAU_NV04) += core/subdev/devinit...

Hey Alex, Thanks. I have a couple of questions and remarks, but really, those should be treated as discussion points rather than anything else. Besides some inline comments, I was curious whether it is not necessary to pause PFIFO and the engines like done with at least NVA3-NVAF? Or is the transition smooth enough? op 10-07-14 09:34, Alexandre Courbot schreef: > Add support for reclocking on GK20A, using a statically-defined pstates > table. The algorithms for calculating the coefficients and setting the > clocks are directly taken from the ChromeOS kernel. >...