2 files changed, 1 insertions, 28 deletions
diff --git a/firmware/export/config/fiiom3k.h b/firmware/export/config/fiiom3k.h
index 99285728a2..115532dc39 100644
@@ -10,19 +10,12 @@
/* CPU defines */
#define CONFIG_CPU X1000
#define X1000_EXCLK_FREQ 24000000
+#define CPU_FREQ 1008000000
#define TIMER_FREQ X1000_EXCLK_FREQ
-#define CPU_FREQ 1008000000
-#define CPUFREQ_MAX CPU_FREQ
-/* TODO: figure out if this does in fact affect power consumption. */
-#define CPUFREQ_DEFAULT (CPUFREQ_MAX/4)
-#define CPUFREQ_NORMAL (CPUFREQ_MAX/4)
/* Kernel defines */
diff --git a/firmware/target/mips/ingenic_x1000/kernel-x1000.c b/firmware/target/mips/ingenic_x1000/kernel-x1000.c
index eb7c3d6124..8d272bdaa9 100644
@@ -23,26 +23,6 @@
-/* TODO: implement a CPU frequency switching policy based on CPU utilization
- * The basic assumption is that the workload consumes a fixed number of CPU
- * cycles per second on average (= utilization), so we can set the frequency
- * based on that value. Audio playback should fit this usage pattern well, so
- * it's a good fit for Rockbox.
- * It's easier to understand in terms of fluid flow -- we need to keep
- * a reservoir of water topped up, CPU frequency is the inflow rate, and
- * CPU utilization is the outflow rate. The goal is to avoid running dry
- * and minimize the inflow rate.
- * The only tricky part here is handing usage spikes -- CPU frequency has to
- * increase faster than utilization or there's a risk of audio dropouts.
- * Rockbox CPU boost could be used as a hint to scale up frequency faster.
- * If that's not necessary to get good results, HAVE_ADJUSTABLE_CPU_FREQ can
- * be disabled entirely.
#define CPU_IDLE_SAMPLES 100
void tick_start(unsigned interval_in_ms)