From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman) Date: Tue, 01 Oct 2013 17:42:18 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0355176065==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 21AFAE779D for ; Tue, 1 Oct 2013 10:42:18 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0355176065== Content-Type: multipart/alternative; boundary="1380649337.0FF12e70.12838"; charset="us-ascii" --1380649337.0FF12e70.12838 Date: Tue, 1 Oct 2013 17:42:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #13 from Alexandre Demers --- (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Just to be sure: vddc is associated only to sclk and vddci to mclk, right? > > > > > > > Not exactly. Mclk is tied to vddci (memory interface voltage), but both > > mclk and sclk (and the core display clock) are tied to vddc (core voltage). > > > > > Also, how are a new freq and a new voltage applied to the card? Are they > > > applied simultanously or sequentially? In the second case, we must be sure > > > to raise voltage before frequency when pushing the performances up, while we > > > should low the frequency before lowering the voltage when we are slowing > > > down. > > > > The actual adjustments are done by a microcontroller on the GPU. You pass a > > set of structures defining the performance levels within the power state to > > the microcontroller and the microcontroller handles the switching. It takes > > into account all of the ordering and chip state dependencies. > > I was asking, just in case there was a manual control over the process and I > would have been in a situation where the card was too near of its limits. > > I changed a little something in the code yesterday and I was lucky enough to > not have any hangs. I just want to be sure it is because of this little > change I've made and not some obscure planets alignment. I'll test it > further today and I'll let you know. Well, it was only luck it seems... I'll send a patch though, since it simplifies a couple of lines. I'll have to continue digging. -- You are receiving this mail because: You are the assignee for the bug. --1380649337.0FF12e70.12838 Date: Tue, 1 Oct 2013 17:42:17 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 13 on bug 69723 from
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Just to be sure: vddc is associated only to sclk and vddci to mclk, right?
> > > 
> > 
> > Not exactly.  Mclk is tied to vddci (memory interface voltage), but both
> > mclk and sclk (and the core display clock) are tied to vddc (core voltage).
> > 
> > > Also, how are a new freq and a new voltage applied to the card? Are they
> > > applied simultanously or sequentially? In the second case, we must be sure
> > > to raise voltage before frequency when pushing the performances up, while we
> > > should low the frequency before lowering the voltage when we are slowing
> > > down.
> > 
> > The actual adjustments are done by a microcontroller on the GPU.  You pass a
> > set of structures defining the performance levels within the power state to
> > the microcontroller and the microcontroller handles the switching.  It takes
> > into account all of the ordering and chip state dependencies.
> 
> I was asking, just in case there was a manual control over the process and I
> would have been in a situation where the card was too near of its limits.
> 
> I changed a little something in the code yesterday and I was lucky enough to
> not have any hangs. I just want to be sure it is because of this little
> change I've made and not some obscure planets alignment. I'll test it
> further today and I'll let you know.

Well, it was only luck it seems... I'll send a patch though, since it
simplifies a couple of lines.

I'll have to continue digging.


You are receiving this mail because:
  • You are the assignee for the bug.
--1380649337.0FF12e70.12838-- --===============0355176065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0355176065==--