[Nouveau] [Bug 27501] MacBook Pro 5, x unable to boot [NV96 + NVAC]
https://bugs.freedesktop.org/show_bug.cgi?id=27501 Pierre Moreau pierre.mor...@free.fr changed: What|Removed |Added Attachment #107262|0 |1 is obsolete|| --- Comment #58 from Pierre Moreau pierre.mor...@free.fr --- Created attachment 110350 -- https://bugs.freedesktop.org/attachment.cgi?id=110350action=edit [Patch] Fix acceleration on 9400M v4 This should be the final verson of this patch, thanks to answers given by the Nvidia guys. Please check that you can use the NVAC with acceleration. If you want to start X or power off the NV96 (if you have one), you will either need to deactivate acceleration for it (noaccel=:02:00.0) or use the trick describe by l3iggs **before** loading Nouveau. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72180] [NVE6] Random GPU Lockups, works with blob PGRAPH fw
https://bugs.freedesktop.org/show_bug.cgi?id=72180 --- Comment #39 from Cedric Brandenbourger ced...@brandenbourger.lu --- I also have this random GPU lookups on my GT660. I tried to get the proprietary PGRAPH working, but without success. Im'getting an error at boot: Failed to loader firmware with error -2 Fallback to user helper Im'using UEFI on debian jessie. I've tried to howto in this forum -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72180] [NVE6] Random GPU Lockups, works with blob PGRAPH fw
https://bugs.freedesktop.org/show_bug.cgi?id=72180 --- Comment #40 from Matthias Nagel matthias.h.na...@gmail.com --- @Cedric: Well this means, that the kernel could not find the firmware. There are several ways how to do it and it depends on wether you have a initramfs or not, if the kernel has access to /lib/fimware when it tries to load the fw, if the the fw is directly included in the kernel or not, if you use an additional boot manager, etc. With UEFI: Does your UEFI directly load the Linux kernel or is there a boot manager in between. For example, I use rEFInd as boot manager, but I guess Debian uses grub2 by default. My setup is the following: (a) Boot manager rEFInd (b) No initramfs (c) FW directly included in kernel. This requires CONFIG_FIRMWARE_IN_KERNEL=y and CONFIG_EXTRA_FIRMWARE=\nouveau/...\ to be set. In my experience, putting the fw directly into the kernel is the easiest way, because one does not need to bother with correct pathes and mount points during boot. Unfortunately, I cannot give you more detailed advices, because I turned my back to Debian long time ago. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] demmio
On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote:
Is this expected result for Chipset: G98 (NV98)?
Yep, 100% expected. [Perhaps you might glance at the wiki page you got
that from for clues as to why.]
$ modinfo nvidia -F version
304.123
$ stat -c %s mmiotrace.log
134659197
$ file mmiotrace.log
mmiotrace.log: ASCII text
$ grep -i lost mmiotrace.log ; echo $?
1
$ ./envytools/rnn/demmio -f mmiotrace.log | perl -e 'open($fh409c,
fuc409c); open($fh409d, fuc409d); open($fh41ac, fuc41ac);
open($fh41ad, fuc41ad);%m = (0x409184 = $fh409c, 0x4091c4 = $fh409d,
0x41a184 = $fh41ac, 0x41a1c4 = $fh41ad);while () { exit if
(/0x409840/); next if (!/W (0x4(?:09|1a)1[c8]4) .* = (?:.*0x)?(.*)/); print
{ $m{$1} } pack I, hex($2);}'
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
$ file fuc4*
fuc409c: empty
fuc409d: empty
fuc41ac: empty
fuc41ad: empty
Ref.
http://nouveau.freedesktop.org/wiki/NVC0_Firmware
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] demmio
On 02.12.2014 14:40, Ilia Mirkin wrote:
On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote:
Is this expected result for Chipset: G98 (NV98)?
Yep, 100% expected. [Perhaps you might glance at the wiki page you got
that from for clues as to why.]
You basically never need to do the mmiotrace, unless you're a nouveau
developer.?
I did everything by the book[1].
Though I don't need this, I still wanted to see how it works with
'nouveau.config=NvGrUseFW=1'.
Bummer.
[1] https://wiki.ubuntu.com/X/MMIOTracing
$ modinfo nvidia -F version
304.123
$ stat -c %s mmiotrace.log
134659197
$ file mmiotrace.log
mmiotrace.log: ASCII text
$ grep -i lost mmiotrace.log ; echo $?
1
$ ./envytools/rnn/demmio -f mmiotrace.log | perl -e 'open($fh409c,
fuc409c); open($fh409d, fuc409d); open($fh41ac, fuc41ac);
open($fh41ad, fuc41ad);%m = (0x409184 = $fh409c, 0x4091c4 =
$fh409d, 0x41a184 = $fh41ac, 0x41a1c4 = $fh41ad);while () { exit if
(/0x409840/); next if (!/W (0x4(?:09|1a)1[c8]4) .* = (?:.*0x)?(.*)/); print
{ $m{$1} } pack I, hex($2);}'
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
I don't know which chipset variant to use!
$ file fuc4*
fuc409c: empty
fuc409d: empty
fuc41ac: empty
fuc41ad: empty
Ref.
http://nouveau.freedesktop.org/wiki/NVC0_Firmware
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] demmio
On Tue, Dec 2, 2014 at 8:50 AM, poma pomidorabelis...@gmail.com wrote: On 02.12.2014 14:40, Ilia Mirkin wrote: On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote: Is this expected result for Chipset: G98 (NV98)? Yep, 100% expected. [Perhaps you might glance at the wiki page you got that from for clues as to why.] You basically never need to do the mmiotrace, unless you're a nouveau developer.? I did everything by the book[1]. Though I don't need this, I still wanted to see how it works with 'nouveau.config=NvGrUseFW=1'. Bummer. You don't just not need it -- you can't possibly use it. Context switching firmware of this sort only exists on nvc0+ (fermi and newer). As the page you got the instructions from suggests (NVC0_Firmware). -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] demmio
On 02.12.2014 14:52, Ilia Mirkin wrote: On Tue, Dec 2, 2014 at 8:50 AM, poma pomidorabelis...@gmail.com wrote: On 02.12.2014 14:40, Ilia Mirkin wrote: On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote: Is this expected result for Chipset: G98 (NV98)? Yep, 100% expected. [Perhaps you might glance at the wiki page you got that from for clues as to why.] You basically never need to do the mmiotrace, unless you're a nouveau developer.? I did everything by the book[1]. Though I don't need this, I still wanted to see how it works with 'nouveau.config=NvGrUseFW=1'. Bummer. You don't just not need it -- you can't possibly use it. Context switching firmware of this sort only exists on nvc0+ (fermi and newer). As the page you got the instructions from suggests (NVC0_Firmware). -ilia AHA! Maxwell and Maxwell only. Bummer. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27501] MacBook Pro 5, x unable to boot [NV96 + NVAC]
https://bugs.freedesktop.org/show_bug.cgi?id=27501 --- Comment #59 from l3iggs j...@greyltc.com --- (In reply to Pierre Moreau from comment #58) Created attachment 110350 [details] [review] [Patch] Fix acceleration on 9400M v4 This should be the final verson of this patch, thanks to answers given by the Nvidia guys. Please check that you can use the NVAC with acceleration. If you want to start X or power off the NV96 (if you have one), you will either need to deactivate acceleration for it (noaccel=:02:00.0) or use the trick describe by l3iggs **before** loading Nouveau. Thanks very much for your work on this Pierre (and thanks to your Nvidia contacts too). With your previous patch, my NVAC was able to start a fully accelerated gnome session via X, although it was very unstable and was quite unusable (however, weston seemed to work fine for me with that patch). With this latest patch, things seem quite stable. I'm writing this from a google-chrome browser in gnome-shell/X and generally things seem to be working so far. ~l3iggs -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86935] New: unknown kepler chipset
https://bugs.freedesktop.org/show_bug.cgi?id=86935 Bug ID: 86935 Summary: unknown kepler chipset Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: sven.koeh...@gmail.com QA Contact: xorg-t...@lists.x.org With Linux 3.17.4, I get the following errors in dmesg: nouveau ![ DEVICE][:01:00.0] unknown Kepler chipset nouveau E[ DEVICE][:01:00.0] unknown chipset, 0xb06070b1 nouveau E[ DRM] failed to create 0x0080, -22 nouveau: probe of :01:00.0 failed with error -22 Obviously, I don't have a framebuffer console during boot and of course nouveau-based X also doesn't work. I'm currently using uvesafb as a workaround. lspci -v output: 01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 730] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CardExpert Technology Device 1287 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f600 (32-bit, non-prefetchable) [size=16M] Memory at e800 (64-bit, prefetchable) [size=128M] Memory at f000 (64-bit, prefetchable) [size=32M] I/O ports at e000 [size=128] Expansion ROM at f700 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Legacy Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting ? Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 ? Kernel modules: nouveau I have no additional details on the card. It came with an HP office PC. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86935] [NV106] unknown kepler chipset 0x106
https://bugs.freedesktop.org/show_bug.cgi?id=86935 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Summary|unknown kepler chipset |[NV106] unknown kepler ||chipset 0x106 --- Comment #1 from Ilia Mirkin imir...@alum.mit.edu --- Yeah, these are the funky GK208B's (often marketed as GT 720?). You can try adding 0x106 right above case 0x108 in drivers/gpu/drm/nouveau/core/engine/device/nve0.c -- they should be identical or at least similar. If that doesn't work, please append a dmesg here (after the patch) and send a mmiotrace of the blob + vbios to mmio.du...@gmail.com -- good guide available at https://wiki.ubuntu.com/X/MMIOTracing -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86935] [NV106] unknown kepler chipset 0x106
https://bugs.freedesktop.org/show_bug.cgi?id=86935 --- Comment #2 from Sven sven.koeh...@gmail.com --- Created attachment 110361 -- https://bugs.freedesktop.org/attachment.cgi?id=110361action=edit the patch proposed in the previous comment Adding 0x106 seems to have worked. I can now boot with nouveau framebuffer and nouveau Xorg driver also works. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86935] [NV106] unknown kepler chipset 0x106
https://bugs.freedesktop.org/show_bug.cgi?id=86935 --- Comment #3 from Sven sven.koeh...@gmail.com --- Will this patch be included in 3.18 (a bit late I guess) or maybe 3.19? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86935] [NV106] unknown kepler chipset 0x106
https://bugs.freedesktop.org/show_bug.cgi?id=86935 --- Comment #4 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to Sven from comment #2) Created attachment 110361 [details] [review] the patch proposed in the previous comment Adding 0x106 seems to have worked. I can now boot with nouveau framebuffer and nouveau Xorg driver also works. Awesome. Please confirm that you're using the nouveau 3d driver (you'll need at least mesa 10.2). Try running some semi-stressing 3d thing too? Not sure if you use gnome-shell or something. [glxgears isn't really enough, although it's a start.] Also, I think it'd still be nice if you could provide a mmiotrace of the blob, the chip could have different golden init values, and other small differences. As for the patch, change it so that the 0x106 case gets a full copy of the 0x108 stuff, and call it GK208B in the name string, and send it as a proper patch (with git format-patch) to nouveau@lists.freedesktop.org . -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86935] [NV106] unknown kepler chipset 0x106
https://bugs.freedesktop.org/show_bug.cgi?id=86935 --- Comment #5 from Sven sven.koeh...@gmail.com --- I will try to do the mmiotrace of the blob. Problem is, that the binary nvidia drivers gives me a kernel OOPS. Yay! Also, while I can make the changes to the kernel source, I'm not really sure what you're asking from me regarding the git format-patch. I'm not really an experienced git user yet. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86935] [NV106] unknown kepler chipset 0x106
https://bugs.freedesktop.org/show_bug.cgi?id=86935 --- Comment #6 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to Sven from comment #5) I will try to do the mmiotrace of the blob. Problem is, that the binary nvidia drivers gives me a kernel OOPS. Yay! D'oh! Maybe try a newer driver? If it oopses later rather than on load/X start, then that should be enough for a mmiotrace. Also, while I can make the changes to the kernel source, I'm not really sure what you're asking from me regarding the git format-patch. I'm not really an experienced git user yet. Step 1: get a git checkout Step 2: Make changes Step 3: git commit -a [pops up editor window, enter in a commit log, subject on first line, blank line, then longer description as necessary, and your sign off] Step 4: git format-patch HEAD^.. Step 5: review the foo.patch file that's generated Step 6: git send-email --to 'nouveau@lists.freedesktop.org' foo.patch [or send it as an email in some other way, just make sure that way preserves little details like tabs] -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH RESEND] nv50/ir: use unordered_set instead of list to keep track of var defs
The set of variable defs does not need to be ordered in any way, and
removing/adding elements is a fairly common operation in various
optimization passes.
This shortens runtime of piglit test fp-long-alu to ~11s from ~22s
No piglit regressions observed on nvc0!
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 4 ++--
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 7 +++---
.../drivers/nouveau/codegen/nv50_ir_inlines.h | 28 +-
.../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 4 ++--
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 6 ++---
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 4 ++--
src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 17 +++--
7 files changed, 38 insertions(+), 32 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index ca3c806..3138118 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -154,9 +154,9 @@ ValueDef::set(Value *defVal)
if (value == defVal)
return;
if (value)
- value-defs.remove(this);
+ value-defs.erase(this);
if (defVal)
- defVal-defs.push_back(this);
+ defVal-defs.insert(this);
value = defVal;
}
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
index 0ff5e5d..56033f1 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h
@@ -567,6 +567,7 @@ public:
inline Value *rep() const { return join; }
+ inline Instruction *getUniqueInsnMerged() const;
inline Instruction *getUniqueInsn() const;
inline Instruction *getInsn() const; // use when uniqueness is certain
@@ -583,11 +584,11 @@ public:
static inline Value *get(Iterator);
std::tr1::unordered_setValueRef * uses;
- std::listValueDef * defs;
+ std::tr1::unordered_setValueDef * defs;
typedef std::tr1::unordered_setValueRef *::iterator UseIterator;
typedef std::tr1::unordered_setValueRef *::const_iterator UseCIterator;
- typedef std::listValueDef *::iterator DefIterator;
- typedef std::listValueDef *::const_iterator DefCIterator;
+ typedef std::tr1::unordered_setValueDef *::iterator DefIterator;
+ typedef std::tr1::unordered_setValueDef *::const_iterator DefCIterator;
int id;
Storage reg;
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
index 255324f..471d47f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_inlines.h
@@ -205,21 +205,26 @@ const LValue *ValueDef::preSSA() const
Instruction *Value::getInsn() const
{
- return defs.empty() ? NULL : defs.front()-getInsn();
+ return defs.empty() ? NULL : (*defs.begin())-getInsn();
}
-Instruction *Value::getUniqueInsn() const
+Instruction *Value::getUniqueInsnMerged() const
{
if (defs.empty())
return NULL;
+ /* It is not guaranteed that this is the first in the set, lets find it */
+ for (DefCIterator it = defs.begin(); it != defs.end(); ++it)
+ if ((*it)-get() == this)
+ return (*it)-getInsn();
+ /* We should never hit this assert */
+ assert(0);
+ return NULL;
+}
- // after regalloc, the definitions of coalesced values are linked
- if (join != this) {
- for (DefCIterator it = defs.begin(); it != defs.end(); ++it)
- if ((*it)-get() == this)
-return (*it)-getInsn();
- // should be unreachable and trigger assertion at the end
- }
+Instruction *Value::getUniqueInsn() const
+{
+ if (defs.empty())
+ return NULL;
#ifdef DEBUG
if (reg.data.id 0) {
int n = 0;
@@ -230,8 +235,9 @@ Instruction *Value::getUniqueInsn() const
WARN(value %%%i not uniquely defined\n, id); // return NULL ?
}
#endif
- assert(defs.front()-get() == this);
- return defs.front()-getInsn();
+ ValueDef *def = *defs.begin();
+ assert(def-get() == this);
+ return def-getInsn();
}
inline bool Instruction::constrainedDefs() const
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
index e283424..f13e0d4 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp
@@ -211,7 +211,7 @@ NV50LegalizePostRA::visit(Function *fn)
if (outWrites) {
for (std::listInstruction *::iterator it = outWrites-begin();
it != outWrites-end(); ++it)
- (*it)-getSrc(1)-defs.front()-getInsn()-setDef(0,
(*it)-getSrc(0));
+ (*(*it)-getSrc(1)-defs.begin())-getInsn()-setDef(0,
(*it)-getSrc(0));
// instructions will be deleted on exit
outWrites-clear();
}
@@ -343,7
Re: [Nouveau] [PATCH] gf116: remove copy1 engine
Reviewed-by: Andy Ritger arit...@nvidia.com On Sun, Nov 30, 2014 at 12:56:18PM -0500, Ilia Mirkin wrote: Indications are that no GF116's actually have a copy engine there, but actually have the decompression engine. This engine can be made to do copies, but that should be done separately. Unclear why this didn't turn up on all GF116's, but perhaps the non-mobile ones came with enough VRAM to not trigger ttm migrations in test scenarios. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168 Cc: sta...@vger.kernel.org Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- nvkm/engine/device/nvc0.c | 1 - 1 file changed, 1 deletion(-) diff --git a/nvkm/engine/device/nvc0.c b/nvkm/engine/device/nvc0.c index cd05677..72a40f9 100644 --- a/nvkm/engine/device/nvc0.c +++ b/nvkm/engine/device/nvc0.c @@ -218,7 +218,6 @@ nvc0_identify(struct nouveau_device *device) device-oclass[NVDEV_ENGINE_BSP] = nvc0_bsp_oclass; device-oclass[NVDEV_ENGINE_PPP] = nvc0_ppp_oclass; device-oclass[NVDEV_ENGINE_COPY0 ] = nvc0_copy0_oclass; - device-oclass[NVDEV_ENGINE_COPY1 ] = nvc0_copy1_oclass; device-oclass[NVDEV_ENGINE_DISP ] = nva3_disp_oclass; device-oclass[NVDEV_ENGINE_PERFMON] = nvc0_perfmon_oclass; break; -- 2.0.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] demmio
On 02.12.2014 14:59, poma wrote: On 02.12.2014 14:52, Ilia Mirkin wrote: On Tue, Dec 2, 2014 at 8:50 AM, poma pomidorabelis...@gmail.com wrote: On 02.12.2014 14:40, Ilia Mirkin wrote: On Tue, Dec 2, 2014 at 8:38 AM, poma pomidorabelis...@gmail.com wrote: Is this expected result for Chipset: G98 (NV98)? Yep, 100% expected. [Perhaps you might glance at the wiki page you got that from for clues as to why.] You basically never need to do the mmiotrace, unless you're a nouveau developer.? I did everything by the book[1]. Though I don't need this, I still wanted to see how it works with 'nouveau.config=NvGrUseFW=1'. Bummer. You don't just not need it -- you can't possibly use it. Context switching firmware of this sort only exists on nvc0+ (fermi and newer). As the page you got the instructions from suggests (NVC0_Firmware). -ilia AHA! Maxwell and Maxwell only. Bummer. Pardon me, Fermi, Kepler and Maxwell only. Bummer^3. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27501] MacBook Pro 5, x unable to boot [NV96 + NVAC]
https://bugs.freedesktop.org/show_bug.cgi?id=27501 Pierre Moreau pierre.mor...@free.fr changed: What|Removed |Added Attachment #110350|0 |1 is obsolete|| --- Comment #60 from Pierre Moreau pierre.mor...@free.fr --- Created attachment 110376 -- https://bugs.freedesktop.org/attachment.cgi?id=110376action=edit [Patch v4.5] Enable non-isometric poller Sorry, there is a new version of the patch to test. The fix is still the same, but it integrates better with the rest of the code. It still works on my laptop but it is best to have some more reports. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Testers needed for NVAA/NVAC kernel patch
Hello everyone,
I would need testers to check that this patch doesn't break working
NVAA/NVAC configurations. It fixes an issue where some NVAC would hang on boot;
if similar issues exist on NVAA, it may fix them too.
You will find the patch below in two different versions: one will apply on Ben
Skeggs' repository, the other one will apply on a regular Linux tree.
Thanks in advance,
Pierre Moreau
If you are using Ben Skeggs' repository:
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
diff --git a/drm/core/subdev/fb/nvaa.h b/drm/core/subdev/fb/nvaa.h
new file mode 12
index 000..b450e8c
--- /dev/null
+++ b/drm/core/subdev/fb/nvaa.h
@@ -0,0 +1 @@
+../../../../nvkm/subdev/fb/nvaa.h
\ No newline at end of file
diff --git a/nvkm/subdev/fb/nv50.h b/nvkm/subdev/fb/nv50.h
index c5e5a88..0b20975 100644
--- a/nvkm/subdev/fb/nv50.h
+++ b/nvkm/subdev/fb/nv50.h
@@ -9,6 +9,10 @@ struct nv50_fb_priv {
dma_addr_t r100c08;
};
+#define nv50_fb_create(p,e,c,d,o)
\
+ nv50_fb_ctor((p), (e), (c), (d), sizeof(**o), \
+ (struct nouveau_object **)o)
+
int nv50_fb_ctor(struct nouveau_object *, struct nouveau_object *,
struct nouveau_oclass *, void *, u32,
struct nouveau_object **);
diff --git a/nvkm/subdev/fb/nvaa.c b/nvkm/subdev/fb/nvaa.c
index cba8e68..b70ab2f 100644
--- a/nvkm/subdev/fb/nvaa.c
+++ b/nvkm/subdev/fb/nvaa.c
@@ -22,15 +22,81 @@
* Authors: Ben Skeggs
*/
-#include nv50.h
+#include nvaa.h
+
+int
+nvaa_fb_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+struct nouveau_oclass *oclass, void *data, u32 size,
+struct nouveau_object **pobject)
+{
+ struct nouveau_device *device = nv_device(parent);
+ struct nvaa_fb_priv *priv;
+ int ret;
+
+ ret = nv50_fb_create(parent, engine, oclass, data, priv);
+ *pobject = nv_object(priv);
+ if (ret)
+ return ret;
+
+ priv = (struct nvaa_fb_priv *)(*pobject);
+
+ priv-r100c18_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (priv-r100c18_page) {
+ priv-r100c18 = dma_map_page(nv_device_base(device),
+priv-r100c18_page, 0, PAGE_SIZE,
+DMA_BIDIRECTIONAL);
+ if (dma_mapping_error(nv_device_base(device), priv-r100c18))
+ return -EFAULT;
+ } else {
+ nv_warn(priv, failed 0x100c18 page alloc\n);
+ }
+ return 0;
+}
+
+void
+nvaa_fb_dtor(struct nouveau_object *object)
+{
+ struct nouveau_device *device = nv_device(object);
+ struct nvaa_fb_priv *priv = (void *)object;
+
+ if (priv-r100c18_page) {
+ dma_unmap_page(nv_device_base(device), priv-r100c18, PAGE_SIZE,
+ DMA_BIDIRECTIONAL);
+ __free_page(priv-r100c18_page);
+ }
+
+ nv50_fb_dtor(object);
+}
+
+int
+nvaa_fb_init(struct nouveau_object *object)
+{
+ struct nvaa_fb_priv *priv = (void *)object;
+ int ret;
+
+ ret = nv50_fb_init(object);
+ if (ret)
+ return ret;
+
+ /* Enable NISO poller for various clients and set their associated
+* read address, only for MCP77/78 and MCP79/7A. (fd#25701)
+*/
+ nv_wr32(priv, 0x100c18, priv-r100c18 8);
+ nv_mask(priv, 0x100c14, 0x, 0x0001);
+ nv_wr32(priv, 0x100c1c, (priv-r100c18 8) + 1);
+ nv_mask(priv, 0x100c14, 0x, 0x0002);
+ nv_wr32(priv, 0x100c24, (priv-r100c18 8) + 2);
+ nv_mask(priv, 0x100c14, 0x, 0x0001);
+ return 0;
+}
struct nouveau_oclass *
nvaa_fb_oclass = (struct nv50_fb_impl) {
.base.base.handle = NV_SUBDEV(FB, 0xaa),
.base.base.ofuncs = (struct nouveau_ofuncs) {
- .ctor = nv50_fb_ctor,
- .dtor = nv50_fb_dtor,
- .init = nv50_fb_init,
+ .ctor = nvaa_fb_ctor,
+ .dtor = nvaa_fb_dtor,
+ .init = nvaa_fb_init,
.fini = _nouveau_fb_fini,
},
.base.memtype = nv50_fb_memtype_valid,
diff --git a/nvkm/subdev/fb/nvaa.h b/nvkm/subdev/fb/nvaa.h
new file mode 100644
index 000..84e1eca
--- /dev/null
+++ b/nvkm/subdev/fb/nvaa.h
@@ -0,0 +1,19 @@
+#ifndef __NVKM_FB_NVAA_H__
+#define __NVKM_FB_NVAA_H__
+
+#include nv50.h
+
+struct nvaa_fb_priv {
+ struct nv50_fb_priv base;
+ struct page *r100c18_page;
+ dma_addr_t r100c18;
+};
+
+int nvaa_fb_ctor(struct nouveau_object *, struct nouveau_object *,
+ struct nouveau_oclass *, void *, u32,
+ struct nouveau_object **);
+void nvaa_fb_dtor(struct nouveau_object *);
+int nvaa_fb_init(struct nouveau_object *);
+
+
+#endif
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Or if you are using the regular tree:
