[Nouveau] [Bug 83168] [NV46] No display after suspend to RAM

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83168

--- Comment #4 from Ilia Mirkin  ---
(In reply to comment #3)
> I think this was like it is for a few months, it isn't a recent  
> regression.

Is that another way of saying that it was working fine a few months ago? Any
idea what kernel worked?

-- 
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 83168] [NV46] No display after suspend to RAM

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83168

--- Comment #3 from Neven Sajko  ---
(In reply to comment #2)
> Has any kernel version worked for you? i.e. is this a recent regression, or
> was it always like this (or even worse)?
> 
> 0x6813c8 = PRMDIO.PAL_INDEX
> 
> The 680* ones are in PRAMDAC but not documented in envytools...
> 
> Weird that the core frequency gets detected as 200 after resume instead of
> 222 as it was on start...

(In reply to comment #2)
> Has any kernel version worked for you? i.e. is this a recent regression, or
> was it always like this (or even worse)?
> 
> 0x6813c8 = PRMDIO.PAL_INDEX
> 
> The 680* ones are in PRAMDAC but not documented in envytools...
> 
> Weird that the core frequency gets detected as 200 after resume instead of
> 222 as it was on start...

I think this was like it is for a few months, it isn't a recent  
regression.

-- 
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] NV25 doesn't draw most icons

2014-08-27 Thread Pavel Roskin

Quoting Ilia Mirkin :


I just sent some patches to the list:

http://lists.freedesktop.org/archives/nouveau/2014-August/018270.html
http://lists.freedesktop.org/archives/nouveau/2014-August/018271.html

Please see if these help your issue.


Yes, the current xf86-video-nouveau fixes my issue completely, even  
with the stock Fedora kernel! Thank you!


Sorry for delay, I was away from that ancient system.

--
Regards,
Pavel Roskin
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 83079] [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83079

--- Comment #10 from Tobias Klausmann  ---
Mh, for me it does not hang, but crashes "back to desktop". (Native Linux
Client)
Nothing in dmesg, just a Memory Access Violation error.

Intel works fine...so something odd in nouveau/gallium.

-- 
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 83168] [NV46] No display after suspend to RAM

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83168

Ilia Mirkin  changed:

   What|Removed |Added

Summary|No display after suspend to |[NV46] No display after
   |RAM |suspend to RAM

--- Comment #2 from Ilia Mirkin  ---
Has any kernel version worked for you? i.e. is this a recent regression, or was
it always like this (or even worse)?

0x6813c8 = PRMDIO.PAL_INDEX

The 680* ones are in PRAMDAC but not documented in envytools...

Weird that the core frequency gets detected as 200 after resume instead of 222
as it was on start...

-- 
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 83168] No display after suspend to RAM

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83168

--- Comment #1 from Neven Sajko  ---
lspci output:
VGA compatible controller: NVIDIA Corporation G72M [Quadro NVS 110M/GeForce Go
7300] (rev a1) (prog-if 00 [VGA controller])

dmesg | grep -i chipset
[0.965969] nouveau  [  DEVICE][:01:00.0] Chipset: G72 (NV46)


Do I have to take a MMIO dump?

-- 
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 83168] New: No display after suspend to RAM

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83168

  Priority: medium
Bug ID: 83168
  Assignee: nouveau@lists.freedesktop.org
   Summary: No display after suspend to RAM
QA Contact: xorg-t...@lists.x.org
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: nsa...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: Driver/nouveau
   Product: xorg

Created attachment 105362
  --> https://bugs.freedesktop.org/attachment.cgi?id=105362&action=edit
the kernel log

When Linux resumes after suspension to RAM, I get no display until next  
boot, but the backlight is on. I think this was true since I started 
using this distro, but I rarely tried to use suspend.   
This happens invariantly to Xorg.   
Although my hardware is 64-bit, I use a 32-bit Linux.   

Software versions:  

* Linux 3.16.1  

* libdrm 2.4.56 

* mesa 10.2.6   

* xf86-video-nouveau 1.0.10 

nouveau reports errors like these to kernel log when the display should 
turn back on:   

[  153.783362] nouveau E[PBUS][:01:00.0] MMIO write of 0x1e00 FAULT
at 0x6813c8
[  153.788735] nouveau E[PBUS][:01:00.0] MMIO write of 0x2e00 FAULT
at 0x6813c8
[  153.791840] nouveau E[PBUS][:01:00.0] MMIO write of 0xf5153d80 FAULT
at 0x6813c8

-- 
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] [PATCH] clock/nva3: Pause the GPU before reclocking

2014-08-27 Thread Ben Skeggs
On Sat, Aug 23, 2014 at 11:04 PM, Roy Spliet  wrote:
> V2: always call post correctly even if pre fails
>
> Signed-off-by: Roy Spliet 
> ---
>  .../gpu/drm/nouveau/core/include/subdev/clock.h|  3 ++
>  drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c   | 52 
> +-
>  drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c   | 36 +--
>  3 files changed, 66 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h 
> b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
> index 676b49e..52e65b8 100644
> --- a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h
> @@ -146,6 +146,9 @@ int nv04_clock_pll_prog(struct nouveau_clock *, u32 reg1,
>  int nva3_clock_pll_calc(struct nouveau_clock *, struct nvbios_pll *,
> int clk, struct nouveau_pll_vals *);
>
> +int nva3_clock_pre(struct nouveau_clock *clk, unsigned long *flags);
> +void nva3_clock_post(struct nouveau_clock *clk, unsigned long *flags);
I'd stick these in the subdev/clock/nva3.h that already exists.

> +
>  int nouveau_clock_ustate(struct nouveau_clock *, int req);
This hunk doesn't apply as-is anyway, due to ustate() gaining an extra
parameter.

I've merged the rest of the patches.

Thanks,
Ben.

>  int nouveau_clock_astate(struct nouveau_clock *, int req, int rel);
>  int nouveau_clock_dstate(struct nouveau_clock *, int req, int rel);
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c 
> b/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c
> index 14a5060..1d1915b 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c
> @@ -23,6 +23,7 @@
>   *  Roy Spliet
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -293,6 +294,41 @@ calc_host(struct nva3_clock_priv *priv, struct 
> nouveau_cstate *cstate)
> return ret;
>  }
>
> +int
> +nva3_clock_pre(struct nouveau_clock *clk, unsigned long *flags)
> +{
> +   struct nouveau_fifo *pfifo = nouveau_fifo(clk);
> +
> +   /* halt and idle execution engines */
> +   nv_mask(clk, 0x020060, 0x0007, 0x);
> +   nv_mask(clk, 0x002504, 0x0001, 0x0001);
> +   /* Wait until the interrupt handler is finished */
> +   if (!nv_wait(clk, 0x000100, 0x, 0x))
> +   return -EBUSY;
> +
> +   if (pfifo)
> +   pfifo->pause(pfifo, flags);
> +
> +   if (!nv_wait(clk, 0x002504, 0x0010, 0x0010))
> +   return -EIO;
> +   if (!nv_wait(clk, 0x00251c, 0x003f, 0x003f))
> +   return -EIO;
> +
> +   return 0;
> +}
> +
> +void
> +nva3_clock_post(struct nouveau_clock *clk, unsigned long *flags)
> +{
> +   struct nouveau_fifo *pfifo = nouveau_fifo(clk);
> +
> +   if (pfifo && flags)
> +   pfifo->start(pfifo, flags);
> +
> +   nv_mask(clk, 0x002504, 0x0001, 0x);
> +   nv_mask(clk, 0x020060, 0x0007, 0x0004);
> +}
> +
>  static void
>  disable_clk_src(struct nva3_clock_priv *priv, u32 src)
>  {
> @@ -421,6 +457,13 @@ nva3_clock_prog(struct nouveau_clock *clk)
>  {
> struct nva3_clock_priv *priv = (void *)clk;
> struct nva3_clock_info *core = &priv->eng[nv_clk_src_core];
> +   int ret = 0;
> +   unsigned long flags;
> +   unsigned long *f = &flags;
> +
> +   ret = nva3_clock_pre(clk, f);
> +   if (ret)
> +   goto out;
>
> if (core->pll)
> prog_core(priv, nv_clk_src_core_intm);
> @@ -430,7 +473,14 @@ nva3_clock_prog(struct nouveau_clock *clk)
> prog_clk(priv, 0x20, nv_clk_src_disp);
> prog_clk(priv, 0x21, nv_clk_src_vdec);
> prog_host(priv);
> -   return 0;
> +
> +out:
> +   if (ret == -EBUSY)
> +   f = NULL;
> +
> +   nva3_clock_post(clk, f);
> +
> +   return ret;
>  }
>
>  static void
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c 
> b/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c
> index 6a65fc9..769ab26 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/nvaa.c
> @@ -299,25 +299,14 @@ static int
>  nvaa_clock_prog(struct nouveau_clock *clk)
>  {
> struct nvaa_clock_priv *priv = (void *)clk;
> -   struct nouveau_fifo *pfifo = nouveau_fifo(clk);
> +   u32 pllmask = 0, mast;
> unsigned long flags;
> -   u32 pllmask = 0, mast, ptherm_gate;
> -   int ret = -EBUSY;
> -
> -   /* halt and idle execution engines */
> -   ptherm_gate = nv_mask(clk, 0x020060, 0x0007, 0x);
> -   nv_mask(clk, 0x002504, 0x0001, 0x0001);
> -   /* Wait until the interrupt handler is finished */
> -   if (!nv_wait(clk, 0x000100, 0x, 0x))
> -   goto resume;
> -
> -   if (pfifo)
> -   pfifo->pause(pfifo, &flags);
> +   unsig

Re: [Nouveau] [PATCH 3/3] therm/nv84+: do not expose non-calibrated internal temp sensor

2014-08-27 Thread Ben Skeggs
On Mon, Aug 25, 2014 at 7:15 AM, Martin Peres  wrote:
> Signed-off-by: Martin Peres 
Hey Martin,

Merged all three patches.

Thanks :)

> ---
>  nvkm/subdev/therm/nv84.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/nvkm/subdev/therm/nv84.c b/nvkm/subdev/therm/nv84.c
> index 38b16d9..14e2e09 100644
> --- a/nvkm/subdev/therm/nv84.c
> +++ b/nvkm/subdev/therm/nv84.c
> @@ -33,7 +33,12 @@ struct nv84_therm_priv {
>  int
>  nv84_temp_get(struct nouveau_therm *therm)
>  {
> -   return nv_rd32(therm, 0x20400);
> +   struct nouveau_fuse *fuse = nouveau_fuse(therm);
> +
> +   if (nv_ro32(fuse, 0x1a8) == 1)
> +   return nv_rd32(therm, 0x20400);
> +   else
> +   return -ENODEV;
>  }
>
>  void
> --
> 2.0.0
>
> ___
> 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] [PATCH envytools] nva: Clean up nva tools doc

2014-08-27 Thread Martin Peres

Whole serie applied (all 7 patches). Thank you again :)

Looking at the patches, it would seem like you were fixing
potential bugs. Remember that envytools is meant for
developers and we like stuff to break in catastrophic ways
when the vbios (for instance) does not follow our expectations.

Of course, crashing or corruption is not acceptable, but I'm all
for a good-old assert or at least big fat warnings. Just don't
waste too much time sanitizing nvbios since it clearly isn't meant
for production.

Thanks again and congrats for actually reading the code and
documentation before contributing! I wish you good luck in
generating the nvc0 memory timings :)

Martin

PS: Sorry it took me so long...
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 83079] [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83079

--- Comment #9 from Ilia Mirkin  ---
I tried to reproduce by replaying the trace, and I didn't get any crashes with
64-bit glretrace. My 32-bit setup is sadly still on mesa 9.2 or 10.0 or
something, and was missing BaseVertex support, so I got a ton of errors.
However also no hang. I'm going to build a fresh 32-bit install to see if I can
reproduce.

Luke: Please confirm what issue you're seeing when doing a glretrace on the
trace you supplied.

-- 
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 83079] [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83079

Luke  changed:

   What|Removed |Added

Summary|[NVC0] Dota 2 under Wine|[NVC0] Dota 2 (Linux native
   |freezes with Nouveau|and Wine) crash with
   |Drivers |Nouveau Drivers

-- 
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 83079] [NVC0] Dota 2 under Wine freezes with Nouveau Drivers

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83079

--- Comment #8 from Luke  ---
@Tobias Klausmann
Good point! You are correct, it also crashes with the native port.

This all started from a similar stack overflow error when I was trying to play
CS:GO which does not have a Linux port. I chose to report Dota 2, because it's
free to play, so it would be easier for others to reproduce.

Simpler Steps to reproduce:
1. Install native Steam under Linux
2. Launch Dota 2
3. Start Bot match. Lock in a hero. OR preview an item in the store

Anything else I can do? Would another apitrace or Dota 2 mini dump help?

-- 
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 83079] [NVC0] Dota 2 under Wine freezes with Nouveau Drivers

2014-08-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83079

--- Comment #7 from Tobias Klausmann  ---
Aa a hint: Why dont you use the native Steam client? Dota2 is available there.
If you can reproduce it there, we have at least spared one layer :)

-- 
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