[3/4] pmu/fuc: call# seems to be broken on gk208

Submitted by Karol Herbst on Feb. 26, 2016, 3:19 p.m.

Details

Message ID 1456499974-1950-4-git-send-email-nouveau@karolherbst.de
State New
Headers show
Series "fix pmu code on gk208+" ( rev: 1 ) in Nouveau

Not browsing as part of any series.

Commit Message

Karol Herbst Feb. 26, 2016, 3:19 p.m.
for some reasons these calls don't really go there where they should go
leading to various corruptions of the PMU state

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
---
 drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 12 ++++++------
 drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc   |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

Patch hide | download patch | download mbox

diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h b/drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h
index 776e672..3c731ff 100644
--- a/drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h
+++ b/drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h
@@ -1036,20 +1036,20 @@  uint32_t gk208_pmu_code[] = {
 /* 0x0193: ticks_from_ns */
 	0xf901f800,
 	0x4db0f9c0,
-	0x21f50144,
-	0xccec0352,
+	0x527e0144,
+	0xccec0003,
 	0xb4b003e8,
 	0x0e0bf400,
 	0x03e8eeec,
-	0xf501444d,
+	0x7e01444d,
 /* 0x01b3: ticks_from_ns_quit */
-	0xb2035221,
+	0xb2000352,
 	0xfcb0fcce,
 /* 0x01bb: ticks_from_us */
 	0xf900f8c0,
 	0x4db0f9c0,
-	0x21f50144,
-	0xceb20352,
+	0x527e0144,
+	0xceb20003,
 	0xf400b4b0,
 	0xe4bd050b,
 /* 0x01d0: ticks_from_us_quit */
diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc b/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc
index d1ca3c7..6839f88 100644
--- a/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc
+++ b/drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc
@@ -252,7 +252,7 @@  ticks_from_ns:
 
 	/* try not losing precision (multiply then divide) */
 	imm32($r13, HW_TICKS_PER_US)
-	call #mulu32_32_64
+	call(mulu32_32_64)
 
 	/* use an immeditate, it's ok because HW_TICKS_PER_US < 16 bits */
 	div $r12 $r12 1000
@@ -264,7 +264,7 @@  ticks_from_ns:
 	/* let's divide then multiply, too bad for the precision! */
 	div $r14 $r14 1000
 	imm32($r13, HW_TICKS_PER_US)
-	call #mulu32_32_64
+	call(mulu32_32_64)
 
 	/* this cannot overflow as long as HW_TICKS_PER_US < 1000 */
 
@@ -286,7 +286,7 @@  ticks_from_us:
 
 	/* simply multiply $us by HW_TICKS_PER_US */
 	imm32($r13, HW_TICKS_PER_US)
-	call #mulu32_32_64
+	call(mulu32_32_64)
 	mov b32 $r14 $r12
 
 	/* check if there wasn't any overflow */

Comments

On 26/02/16 17:19, Karol Herbst wrote:
> for some reasons these calls don't really go there where they should go
> leading to various corruptions of the PMU state

I am fine with the changes but not fine at all with the commit message. 
it would be nice if you could understand a bit more what the problem is 
instead of just saying: "it works with this change (TM)"

Anyway, 1-3 are:

Reviewed-by: Martin Peres <martin.peres@free.fr>
On Tue, Mar 1, 2016 at 4:45 PM, Martin Peres <martin.peres@free.fr> wrote:
> On 26/02/16 17:19, Karol Herbst wrote:
>>
>> for some reasons these calls don't really go there where they should go
>> leading to various corruptions of the PMU state
>
>
> I am fine with the changes but not fine at all with the commit message. it
> would be nice if you could understand a bit more what the problem is instead
> of just saying: "it works with this change (TM)"

The problem is that the call macro exists for a reason, but it was
(accidentally) not being used here.

>
> Anyway, 1-3 are:
>
> Reviewed-by: Martin Peres <martin.peres@free.fr>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
On 01/03/16 23:53, Ilia Mirkin wrote:
> On Tue, Mar 1, 2016 at 4:45 PM, Martin Peres <martin.peres@free.fr> wrote:
>> On 26/02/16 17:19, Karol Herbst wrote:
>>> for some reasons these calls don't really go there where they should go
>>> leading to various corruptions of the PMU state
>>
>> I am fine with the changes but not fine at all with the commit message. it
>> would be nice if you could understand a bit more what the problem is instead
>> of just saying: "it works with this change (TM)"
> The problem is that the call macro exists for a reason, but it was
> (accidentally) not being used here.

Agreed, I checked before sending this email. Hence why I was fine with 
the change but not the change log.