Skip to contentSkip to conversation

cpufreq powernow-k8: Remove firmware warning in zero transition latency case

PATCH In review Thomas Renninger 2 participants 3 messages Jun 8, 2011 CPU frequency scaling framework

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 cpufreq powernow-k8: Remove firmware warning in zero transition latency case

AMD's BKDG documents that a zero transition latency should get passed for several recent CPU models.
-> This isn't a firmware bug.

I did not dare to really pass the zero latency to the cpufreq core, this would need careful checking whether this does not show side effects. -> Still modify latency to 1 (us) in case BIOS passes zero.

---
 drivers/cpufreq/powernow-k8.c |   13 ++-----------
 1 files changed, 2 insertions(+), 11 deletions(-)
drivers/cpufreq/powernow-k8.c +2 -11
index 83479b6..170ad36 100644
@@ -1022,18 +1022,9 @@ static int get_transition_latency(struct powernow_k8_data *data)
 		if (cur_latency > max_latency)
 			max_latency = cur_latency;
 	}
-	if (max_latency == 0) {
-		/*
-		 * Fam 11h and later may return 0 as transition latency. This
-		 * is intended and means "very fast". While cpufreq core and
-		 * governors currently can handle that gracefully, better set it
-		 * to 1 to avoid problems in the future.
-		 */
-		if (boot_cpu_data.x86 < 0x11)
-			printk(KERN_ERR FW_WARN PFX "Invalid zero transition "
-				"latency\n");
+	if (max_latency == 0)
 		max_latency = 1;
-	}
+
 	/* value in usecs, needs to be in nanoseconds */
 	return 1000 * max_latency;
 }
#1 lore raw
Quoted 3 lines · Thomas Renninger

AMD's BKDG documents that a zero transition latency should get passed for several recent CPU models.
-> This isn't a firmware bug.

but the test you're deleting is checking for family < 11h.
My reading of that comment is that it _was_ a firmware bug on earlier systems.

Dave

#2 lore raw
Quoted 6 lines · Dave Jones
Quoted 3 lines · Thomas Renninger

AMD's BKDG documents that a zero transition latency should get passed for several recent CPU models.
-> This isn't a firmware bug.

but the test you're deleting is checking for family < 11h.

Eh, right. And in 2.6.32 we had:
- if (boot_cpu_data.x86 != 0x11)
which I now removed and wanted to submit mainline...

Quoted 2 lines

My reading of that comment is that it _was_ a firmware bug on earlier systems.

Not sure whether earlier systems really showed this, but the test is correct, you can ignore the patch.

Thanks for pointing that out,

Thomas