similar to: [Bug 103409] New: [GM107] reboot/suspend/lspci hang with nouveau

>>>>> Tal Galili <tal.galili at gmail.com> >>>>> on Mon, 18 May 2015 23:01:44 +0300 writes: > The problem: > =========== > Once a dendrogram has a branch with both a line type AND a color (which is > a character color), the plot.dendrogram function will not plot and return > an error. If the dendrogram has been messed up

The problem: =========== Once a dendrogram has a branch with both a line type AND a color (which is a character color), the plot.dendrogram function will not plot and return an error. I say this is a bug because (I believe), we would like a dendrogram to be able to use character colors, while also allowing control over line types. This e-mail includes an example, and what I think a solution

Hi all, I think I have some problems to use correctly the function dendrapply. Let suppose dend is a dendrogram object. I would likde to know the cardinal number of leaves depending of each node of the tree dend. It is right that the command attr(dend,"members") gives the total number of leaves, and attr(dend[[1]],"members") gives the number of leaves for the first left

Spotted by coccinelle: drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/nvkm/subdev/fuse/gm107.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/fuse/gm107.c b/drm/nouveau/nvkm/subdev/fuse/gm107.c index ba19158..0b256aa 100644

Patch "ltc/gm107: use nvkm_mask to set cbc_ctrl1" sets the 3rd bit of the CTRL1 register instead of writing it entirely in gm107_ltc_cbc_clear(). As a counterpart, gm107_ltc_cbc_wait() must also be modified to wait on that single bit only, otherwise a timeout may occur if some other bit of that register is set. This happened at least on GM206 when running glmark2-drm. While we are at

We get 1 warning when build kernel with W=1: drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c:312:1: warning: no previous prototype for 'gm107_gr_init' [-Wmissing-prototypes] In fact, this function is only used in the file in which it is declared and don't need a declaration, but can be made static. so this patch marks this function with 'static'. Signed-off-by: Baoyou Xie

Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nvkm/subdev/fb/gm107.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/fb/gm107.c b/drm/nouveau/nvkm/subdev/fb/gm107.c index 2a91df8..9cc7e61 100644 --- a/drm/nouveau/nvkm/subdev/fb/gm107.c +++ b/drm/nouveau/nvkm/subdev/fb/gm107.c @@ -29,7 +29,7 @@ gm107_fb = { .dtor =

Unfortunately there's no sure-fire way to distinguish a sched "op" from regular ones. They happen purely based on position. So for disassembly, use the byte position in the file to determine whether the current op should be decoded as sched or as regular. For assembly, we go back to using a shared table. Ideally we would pick out which one to use based on the position in the

Hello all, I've run into what I bet is a silly problem; however, I've been trying to get around it now for a couple weeks and every time I think I have the answer it still doesn't work. So I apologize in advance if this is painfully obvious, but I've run out of ideas and would really appreciate any input. My situation is this, I'm importing a number of tab

https://bugs.freedesktop.org/show_bug.cgi?id=98391 Bug ID: 98391 Summary: [GM107] priv: HUB0: 614900 00800000 (1d408200) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=106662 Bug ID: 106662 Summary: nouveau DPMS poblem with DRI3 (GM107) Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=90054 Bug ID: 90054 Summary: white screen reboot on gm107 with multiple monitors Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=106132 Bug ID: 106132 Summary: bar.sync encoding incorrect for GM107 Product: Mesa Version: git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

hi all, i'm trying to plot a dendrogram with labeled leaves >rownames(f)<-v.names >v<-rowMeans(f, na.rm=T) >clust<-hclust(dist(v)) >dend<-as.dendrogram(clust,hang=0.05) >clust2<-cut(dend, h=0.5) >class(clust2$low[[1]]) >[1] "dendrogram" then >plot(clust2$low[[1]],horiz=TRUE,frame=F,type = "tr")) but my leaf labels do not fit

There is no dedicated instruction for this, so just combine it with the constant offset. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.3" <mesa-stable at lists.freedesktop.org> --- This fixes the spec/glsl-1.50/execution/geometry/dynamic_input_array_index piglit test. src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_gm107.cpp | 5 ++++- 1 file changed,

Hello, The method we previously used on Fermi and Kepler (0x142c) to flush the VBO cache before draw appears to be gone on Maxwell. Is there a replacement method we should use? (Or perhaps that method was never meant for VBO cache flush and instead flushed something related to the vertex quarantine area defined by 0x17bc/0x17c0/0x17c4, which in turn is gone on Maxwell?) Thanks for any light you

From: Martin Peres <martin.peres at labri.fr> Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/subdev/therm/gm107.c | 1 + nvkm/engine/device/gm100.c | 4 +- nvkm/include/subdev/therm.h | 1 + nvkm/subdev/therm/Makefile.am | 3 +- nvkm/subdev/therm/fan.c | 9 ++++- nvkm/subdev/therm/gm107.c | 93

So I'm trying to track an special value in IPA instruction generation. https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp#L2561 Register on 0x14 (20) is set to some source on "insn->op == OP_PINTERP" I have found while emulation that such value can be set sometimes to FragCoord.w, I don't however know what that value is and

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.3" <mesa-stable at lists.freedesktop.org> --- With this, all the tex-miplevel-selection tests pass on maxwell. There is a minor bit of this change which affects textureGrad on kepler that I have yet to test, but I'm moderately sure it's correct and was only working by luck before. (Changing the insbf to use

Just like how the P50 will occasionally leave the disp's core channel on before nouveau starts initializing, it will occasionally do the same thing with the rest of the dmac channel in addition to the core channel. Example: [ 1.604375] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: no heads (0 3 4) [ 1.604858] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: aux power -> always [