diff --git a/utils/tuning/raspberrypi.py b/utils/tuning/raspberrypi.py
new file mode 100644
index 00000000..8e963743
--- /dev/null
+++ b/utils/tuning/raspberrypi.py
@@ -0,0 +1,44 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2022, Paul Elder <paul.elder@ideasonboard.com>
+#
+# raspberrypi.py - Tuning script for raspberrypi
+
+import sys
+
+import libtuning as lt
+from libtuning.modules import AWB
+from libtuning.parsers import RaspberryPiParser
+from libtuning.generators import RaspberryPiOutput
+
+from raspberrypi.alsc import ALSC
+
+tuner = lt.Camera('Raspberry Pi')
+
+# These modules can also be custom modules. libtuning will come with utilities
+# for handling stuff like images, so there shouldn't be too much boilerplate
+# involved in creating custom modules, though I don't yet have a concrete
+# vision on how custom implementations of modules would look.
+tuner.add(ALSC)
+
+# Other tuning modules can be added like so.
+# The order that the tuning modules will be executed is determined by the order
+# that they're added.
+# This is kind of an implementation detail, but the "context" is saved
+# internally in lt.Camera, so modules that are added (and therefore executed)
+# later can use the output of the previous modules. I'm thinking that a module
+# that depends on values from another module has two modes of execution, for
+# when those values are available and another for when they're not. Not quite
+# sure concretely how to handle this yet.
+tuner.add(AWB(  # module parameters
+))
+
+tuner.setInputType(RaspberryPiParser)
+tuner.setOutputType(RaspberryPiOutput)
+
+# The order of the output doesn't necessarily have to be the same as the order
+# of input, which is specified by the order of adding the modules above.
+tuner.setOutputOrder([AWB, ALSC])
+
+tuner.run(sys.argv)