vchiq, fbdev, thermal, cpufreq: Use the new firmware API

[notro]

Tested on Pi1 and Pi2 with and without Device Tree + ARCH_BCM2835.

Initially I planned to get the thermal and cpufreq drivers upstream, but the process is very slow and I still have a couple of patches that haven't been accepted into mainline yet. My hobby development environment doesn't handle multiple long running tasks very well.

Test details

Thermal

$ cat /sys/class/thermal/thermal_zone0/temp && vcgencmd measure_temp
39007
temp=39.0'C

cpufreq

$ head -1 /boot/config.txt
arm_freq=900

# Pi1
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq && vcgencmd measure_clock arm
700000
frequency(45)=700000000
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
700000

# Pi2
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq && vcgencmd measure_clock arm
600000
frequency(45)=600000000
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
600000

$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
900000

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

$ echo performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq && vcgencmd measure_clock arm
900000
frequency(45)=900000000

$ echo powersave | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Pi1
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq && vcgencmd measure_clock arm
700000
frequency(45)=700000000

# Pi2
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq && vcgencmd measure_clock arm
600000
frequency(45)=600000000

bcm2708_fb Colour palette

$ wget http://malus.exotica.org.uk/~buzz/pi/sdl/sdl1/deb/rpi1/libsdl1.2debian_1.2.15-8rpi_armhf.deb
$ wget http://malus.exotica.org.uk/~buzz/pi/sdl/sdl1/deb/rpi1/libsdl1.2-dev_1.2.15-8rpi_armhf.deb
$ sudo dpkg -i libsdl1.2debian_1.2.15-8rpi_armhf.deb libsdl1.2-dev_1.2.15-8rpi_armhf.deb
$ sudo apt-get -f install

$ wget http://marklomas.net/ch-egg/downloads/ch-egg-port-sdl-source_v1_1.zip
$ unzip ch-egg-port-sdl-source_v1_1.zip
$ cd ch-egg-port-sdl-source_v1.1/ch-egg/bbcb
$ gcc -Os -I/usr/include/SDL -c sound.c mode2font.c r6502main.c
$ ar cr libbbcb.a sound.o r6502main.o mode2font.o
$ cd ..
$ gcc -Os -I/usr/include/SDL -I../ execute.c library.c main.c -Lbbcb -lbbcb -lSDL -lm
$ mv a.out ../ch-egg.elf

# Audio is necessary: /boot/config.txt
# dtparam=audio=on

$ ./ch-egg-port-sdl-source_v1.1/ch-egg.elf

bcm2708_fb Ioctl: FBIOPAN_DISPLAY and FBIO_WAITFORVSYNC

$ wget https://raw.githubusercontent.com/rst-/raspberry-compote/master/fb/fbtestXIV.c
$ gcc -O2 -o fbtestXIV fbtestXIV.c
$ ./fbtestXIV

bcm2708_fb Blanking

$ setterm -blank 1

[pelwell]

I've got a few questions:

1. Why do we have to use a Pi-specific exported function (rpi_firmware_get) in order to use the preferred way to communicate with firmware? I would have expected there to be a helper function

2. Why does VCHIQ go to the trouble of finding the firmware node to pass to rpi_firmware_get (where it is ignored...) while the cpufreq driver just passes NULL?

[notro]

1. Why do we have to use a Pi-specific exported function (rpi_firmware_get) in order to use the preferred way to communicate with firmware? I would have expected there to be a helper function

rpi_firmware_get() is the way drivers get access to the firmware API. Pass in the firmware device DT node and get back a pointer to the firmware struct. A lookup function like say of_find_backlight_by_node() that converts a DT node to the backlight device instance.
Even though it's highly unlikely that more than one firmware will ever exist, kernel code always have to assume that more than one instance can exist.

Since we support booting without DT, rpi_firmware_get() had to be modified: https://github.com/notro/linux/commit/574b79f8d5f09c2454b16328dc6f1097c63aaf13
The mailbox subsystem (and driver) also had to be modified: https://github.com/notro/linux/commit/6cc11b0c82b458298434c76e8727fe18599bbbc6

2. Why does VCHIQ go to the trouble of finding the firmware node to pass to rpi_firmware_get (where it is ignored...) while the cpufreq driver just passes NULL?

vchiq is prepared for the time when booting without DT is no longer supported and we drop the downstream patch.
As for cpufreq, it isn't a driver that is initiated from Device Tree, it's just a module. So it would need some work to become a platform driver. When Eric Anholt mentioned in an email that someone was working on a cpufreq driver for mainline, I took a shortcut on this one.