[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98582

hoboprim...@gmail.com changed:

   What|Removed |Added

 Attachment #127737|0   |1
is obsolete||

--- Comment #8 from hoboprim...@gmail.com ---
Created attachment 127779
  --> https://bugs.freedesktop.org/attachment.cgi?id=127779=edit
*full* log of failed resuming on 4.8.4

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98582

--- Comment #7 from hoboprim...@gmail.com ---
Took a while to compile the 4.7 kernel :) (from fedora sources), and the
chipset was recognized with it (see attached log). Resuming from suspend also
failed there.

Also attached acpidump output.

Also just realized, I have not been attaching *full* boot logs, i.e., up to the
point it fails to wake from suspension. I will do that (right after this
comment) on the current 4.8.4 kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98582

--- Comment #6 from hoboprim...@gmail.com ---
Created attachment 127778
  --> https://bugs.freedesktop.org/attachment.cgi?id=127778=edit
acpidump output

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98582

--- Comment #5 from hoboprim...@gmail.com ---
Created attachment 12
  --> https://bugs.freedesktop.org/attachment.cgi?id=12=edit
'journalctl -b' output when running kernel 4.7

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] nouveau: remove unused variables

2016-11-04 Thread Karol Herbst 
I am a little unsure about the change in nouveau_fence, maybe somebody
with more knowledge about the code can look into it?

Signed-off-by: Karol Herbst 
---
 drm/nouveau/dispnv04/arb.c| 6 ++
 drm/nouveau/nouveau_fence.c   | 2 --
 drm/nouveau/nvkm/subdev/fb/ramgk104.c | 4 +---
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drm/nouveau/dispnv04/arb.c b/drm/nouveau/dispnv04/arb.c
index a555681..4bbd83a 100644
--- a/drm/nouveau/dispnv04/arb.c
+++ b/drm/nouveau/dispnv04/arb.c
@@ -55,8 +55,8 @@ struct nv_sim_state {
 static void
 nv04_calc_arb(struct nv_fifo_info *fifo, struct nv_sim_state *arb)
 {
-   int pagemiss, cas, width, bpp;
-   int nvclks, mclks, pclks, crtpagemiss;
+   int pagemiss, cas, bpp;
+   int nvclks, mclks, crtpagemiss;
int found, mclk_extra, mclk_loop, cbs, m1, p1;
int mclk_freq, pclk_freq, nvclk_freq;
int us_m, us_n, us_p, crtc_drain_rate;
@@ -67,11 +67,9 @@ nv04_calc_arb(struct nv_fifo_info *fifo, struct nv_sim_state 
*arb)
nvclk_freq = arb->nvclk_khz;
pagemiss = arb->mem_page_miss;
cas = arb->mem_latency;
-   width = arb->memory_width >> 6;
bpp = arb->bpp;
cbs = 128;
 
-   pclks = 2;
nvclks = 10;
mclks = 13 + cas;
mclk_extra = 3;
diff --git a/drm/nouveau/nouveau_fence.c b/drm/nouveau/nouveau_fence.c
index 098044c..e1ead6f 100644
--- a/drm/nouveau/nouveau_fence.c
+++ b/drm/nouveau/nouveau_fence.c
@@ -154,10 +154,8 @@ nouveau_fence_wait_uevent_handler(struct nvif_notify 
*notify)
spin_lock_irqsave(>lock, flags);
if (!list_empty(>pending)) {
struct nouveau_fence *fence;
-   struct nouveau_channel *chan;
 
fence = list_entry(fctx->pending.next, typeof(*fence), head);
-   chan = rcu_dereference_protected(fence->channel, 
lockdep_is_held(>lock));
if (nouveau_fence_update(fence->channel, fctx))
ret = NVIF_NOTIFY_DROP;
}
diff --git a/drm/nouveau/nvkm/subdev/fb/ramgk104.c 
b/drm/nouveau/nvkm/subdev/fb/ramgk104.c
index 7904fa4..fb8a123 100644
--- a/drm/nouveau/nvkm/subdev/fb/ramgk104.c
+++ b/drm/nouveau/nvkm/subdev/fb/ramgk104.c
@@ -989,7 +989,7 @@ gk104_pll_calc_hiclk(int target_khz, int crystal,
int *N1, int *fN1, int *M1, int *P1,
int *N2, int *M2, int *P2)
 {
-   int best_clk = 0, best_err = target_khz, p_ref, n_ref;
+   int best_err = target_khz, p_ref, n_ref;
bool upper = false;
 
*M1 = 1;
@@ -1010,7 +1010,6 @@ gk104_pll_calc_hiclk(int target_khz, int crystal,
/* we found a better combination */
if (cur_err < best_err) {
best_err = cur_err;
-   best_clk = cur_clk;
*N2 = cur_N;
*N1 = n_ref;
*P1 = p_ref;
@@ -1022,7 +1021,6 @@ gk104_pll_calc_hiclk(int target_khz, int crystal,
- target_khz;
if (cur_err < best_err) {
best_err = cur_err;
-   best_clk = cur_clk;
*N2 = cur_N;
*N1 = n_ref;
*P1 = p_ref;
-- 
2.10.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2] gr: fallback to legacy paths during firmware lookup

2016-11-04 Thread Alexandre Courbot 
Look for firmware files using the legacy ("nouveau/nvxx_fuc") path
if they cannot be found in the new, "official" path. User setups were
broken by the switch, which is bad.

There are only 4 firmware files we may want to look up that way, so
hardcode them into the lookup function. All new firmware files should
use the standard "nvidia//gr/" path.

Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external firmwares")
Signed-off-by: Alexandre Courbot 
---
Changes since v1:
* Moved file name translation into the legacy function

 drm/nouveau/nvkm/engine/gr/gf100.c | 53 +++---
 1 file changed, 49 insertions(+), 4 deletions(-)

diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c 
b/drm/nouveau/nvkm/engine/gr/gf100.c
index eccdee04107d..ed45f923442f 100644
--- a/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -1756,6 +1756,53 @@ gf100_gr_ = {
 };
 
 int
+gf100_gr_ctor_fw_legacy(struct gf100_gr *gr, const char *fwname,
+   struct gf100_gr_fuc *fuc, int ret)
+{
+   struct nvkm_subdev *subdev = >base.engine.subdev;
+   struct nvkm_device *device = subdev->device;
+   const struct firmware *fw;
+   char f[32];
+
+   /* see if this firmware has a legacy path */
+   if (!strcmp(fwname, "fecs_inst"))
+   fwname = "fuc409c";
+   else if (!strcmp(fwname, "fecs_data"))
+   fwname = "fuc409d";
+   else if (!strcmp(fwname, "gpccs_inst"))
+   fwname = "fuc41ac";
+   else if (!strcmp(fwname, "gpccs_data"))
+   fwname = "fuc41ad";
+   else
+   fwname = NULL;
+
+   /* nope, let's just return the error we got */
+   if (!fwname) {
+   nvkm_error(subdev, "failed to load %s\n", fwname);
+   return ret;
+   }
+
+   /* yes, try to load from the legacy path */
+   nvkm_debug(subdev, "%s: falling back to legacy path\n", fwname);
+
+   snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname);
+   ret = request_firmware(, f, device->dev);
+   if (ret) {
+   snprintf(f, sizeof(f), "nouveau/%s", fwname);
+   ret = request_firmware(, f, device->dev);
+   if (ret) {
+   nvkm_error(subdev, "failed to load %s\n", fwname);
+   return ret;
+   }
+   }
+
+   fuc->size = fw->size;
+   fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
+   release_firmware(fw);
+   return (fuc->data != NULL) ? 0 : -ENOMEM;
+}
+
+int
 gf100_gr_ctor_fw(struct gf100_gr *gr, const char *fwname,
 struct gf100_gr_fuc *fuc)
 {
@@ -1765,10 +1812,8 @@ gf100_gr_ctor_fw(struct gf100_gr *gr, const char *fwname,
int ret;
 
ret = nvkm_firmware_get(device, fwname, );
-   if (ret) {
-   nvkm_error(subdev, "failed to load %s\n", fwname);
-   return ret;
-   }
+   if (ret)
+   return gf100_gr_ctor_fw_legacy(gr, fwname, fuc, ret);
 
fuc->size = fw->size;
fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
-- 
2.10.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Atomic modesetting + DisplayPort MST

2016-11-04 Thread Ben Skeggs 
Hey all,

I've just pushed out the initial Nouveau support for $subject \o/

As the atomic modesetting transition is basically a rewrite of the KMS
portion of the driver, I would be very grateful for any additional
testing that people could provide (even as simple as just booting and
making sure you get a display is valuable).

There's a Linux tree at
https://github.com/skeggsb/linux/tree/linux-4.10, and the code also
exists in my usual development tree[1] on the master branch (which is
currently based on Dave's drm-next tree for Linux 4.10).

There's another branch (devel-kms) in the same repository, which is the
same code on top of what's currently Linux 4.9.  If you have problems
with the 4.10 code, I'd definitely be interested in seeing if they exist
on the 4.9 branch too.

Thanks in advance!
Ben.

[1] https://github.com/skeggsb/nouveau



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98457] [NVD9] GPU lockup after resume from hibernation with Nouveau driver and firmware-nonfree

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98457

--- Comment #3 from Pierre Moreau  ---
(In reply to wadev from comment #1)
> I tried the trunk (of 2016-10-27) of mesa, libdrm and xf86-video-nouveau, no
> dice.
> I could not, however, try the kernel driver (which I presume is mainly for
> text mode and probably comprises the framebuffer backend of the libdrm), as
> I am at 4.8.4 now and the nouveau kernel driver repository is fit for some
> such arcane kernel version that it has been removed even from OpenVZ and
> such. :P
> 
> If anyone has some ideas on how to find an "edger" repository of the nouveau
> kernel driver object that is ahead of the kernel.org state (if any), please
> let me know.

You could try https://github.com/skeggsb/linux/tree/linux-4.10 which has the
latest patches, but is not an out-of-tree version. Or the latest image from
https://nouveau.pmoreau.org/ (though it is not as recent as the previous link,
as the image was generated on Monday).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98457] [NVD9] GPU lockup after resume from hibernation with Nouveau driver and firmware-nonfree

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98457

--- Comment #2 from wa...@mailbox.hu ---
I've added #97462 as "related", since the symptom seems exactly the same.

The only difference is that while that one could have been reproduced - by me -
only with Firefox Beta && ESR and Google Maps, presumably with all
"force-enabled" settings, while suspend-to-disk and resume was unaffected,
this one is not reproduced by Firefox settings and websites, but instead
happens on each and every resume from hibernation.

For the inexperienced eye, it might just appear that the computer is almost
completely hung, with the desktop environment showing the time of the
hibernation, and the mouse cursor is the only symptom of actual functionality,
and even that is only for a while.

If, however, someone hibernates with "echo disk >/sys/power/state" from a real
console (not an X terminal), one gets the messages below.

This explanation above is mainly added for search engine indexing reasons, may
someone find their problem accordingly.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 97462] Graphics deadlock "ILLEGAL_MTHD" in nouveau with mesa version 11.2.2 when visiting Google Maps with firefox 49.0b5

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97462

wa...@mailbox.hu changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=98457

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98457] [NVD9] GPU lockup after resume from hibernation with Nouveau driver and firmware-nonfree

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98457

wa...@mailbox.hu changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=97462

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98457] [NVD9] GPU lockup after resume from hibernation with Nouveau driver and firmware-nonfree

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98457

--- Comment #1 from wa...@mailbox.hu ---
I tried the trunk (of 2016-10-27) of mesa, libdrm and xf86-video-nouveau, no
dice.
I could not, however, try the kernel driver (which I presume is mainly for text
mode and probably comprises the framebuffer backend of the libdrm), as I am at
4.8.4 now and the nouveau kernel driver repository is fit for some such arcane
kernel version that it has been removed even from OpenVZ and such. :P

If anyone has some ideas on how to find an "edger" repository of the nouveau
kernel driver object that is ahead of the kernel.org state (if any), please let
me know.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98582] A regression with nouveau under wayland+xorg: laptop doesn't resume properly from suspension

2016-11-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98582

--- Comment #4 from Pierre Moreau  ---
Support for GM108 chipsets was merged in Linux 4.7, which was released end of
July 2016, so I assume that it worked before as Nouveau failed to recognise the
chipset, and therefore did nothing.

Trying Linux 4.7 and making sure that the chipset is recognised would be nice,
to rule out a possible regression. Could you also please add the output of
acpidump to the bug report?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau