tools/power/cpupower/{ToDo => TODO}: Rename the todo file

Renamed the to-do file to 'TODO' instead of 'ToDo' to
comply with the naming standard.

Signed-off-by: ozkanonur <onurozkan.dev@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

diff --git a/tools/power/cpupower/TODO b/tools/power/cpupower/TODO
new file mode 100644 (file)
index 0000000..b196a13
--- /dev/null
+++ b/tools/power/cpupower/TODO
@@ -0,0 +1,24 @@
+ToDos sorted by priority:
+
+- Use bitmask functions to parse CPU topology more robust
+  (current implementation has issues on AMD)
+- Try to read out boost states and frequencies on Intel
+- Somewhere saw the ability to read power consumption of
+  RAM from HW on Intel SandyBridge -> another monitor?
+- Add another c1e debug idle monitor
+  -> Is by design racy with BIOS, but could be added
+     with a --force option and some "be careful" messages
+- Add cpu_start()/cpu_stop() callbacks for monitor
+  -> This is to move the per_cpu logic from inside the
+     monitor to outside it. This can be given higher
+     priority in fork_it.
+- Fork as many processes as there are CPUs in case the
+  per_cpu_schedule flag is set.
+  -> Bind forked process to each cpu.
+  -> Execute start measures via the forked processes on
+     each cpu.
+  -> Run test executable in a forked process.
+  -> Execute stop measures via the forked processes on
+     each cpu.
+  This would be ideal as it will not introduce noise in the
+  tested executable.

diff --git a/tools/power/cpupower/ToDo b/tools/power/cpupower/ToDo
deleted file mode 100644 (file)
index b196a13..0000000
--- a/tools/power/cpupower/ToDo
+++ /dev/null
@@ -1,24 +0,0 @@
-ToDos sorted by priority:
-
-- Use bitmask functions to parse CPU topology more robust
-  (current implementation has issues on AMD)
-- Try to read out boost states and frequencies on Intel
-- Somewhere saw the ability to read power consumption of
-  RAM from HW on Intel SandyBridge -> another monitor?
-- Add another c1e debug idle monitor
-  -> Is by design racy with BIOS, but could be added
-     with a --force option and some "be careful" messages
-- Add cpu_start()/cpu_stop() callbacks for monitor
-  -> This is to move the per_cpu logic from inside the
-     monitor to outside it. This can be given higher
-     priority in fork_it.
-- Fork as many processes as there are CPUs in case the
-  per_cpu_schedule flag is set.
-  -> Bind forked process to each cpu.
-  -> Execute start measures via the forked processes on
-     each cpu.
-  -> Run test executable in a forked process.
-  -> Execute stop measures via the forked processes on
-     each cpu.
-  This would be ideal as it will not introduce noise in the
-  tested executable.