bcm2835: Add Raspberry Pi CPU frequency control to the device tree
Subsystems (4)
PATCH 1/1 bcm2835: Add Raspberry Pi CPU frequency control to the device tree
This adds a device tree binding for Broadcom BCM2834 CPU frequency control driven via Raspberry Pi VideoCore 4 firmware interface.
---
Depends on the RPi Firmware driver submitted on linux-rpi-kernel a while ago. Can't see it in arm-soc or linux-next yet though (?). Available in branch 'rpi-firmware' of https://github.com/anholt/linux
.../bindings/cpufreq/raspberrypi,bcm2835-cpufreq.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/raspberrypi,bcm2835-cpufreq.txt
Documentation/devicetree/bindings/cpufreq/raspberrypi,bcm2835-cpufreq.txt new file +13 -0
@@ -0,0 +1,13 @@ +Raspberry Pi Broadcom BCM2835 CPU frequency control + +Required properties: + +- compatible : should be "raspberrypi,bcm2835-cpufreq" +- firmware : the Raspberry Pi firmware node + +Example: + +cpufreq { + compatible = "raspberrypi,bcm2835-cpufreq"; + firmware = <&firmware>; +};
Signature · 1 line
2.4.3
PATCH 1/1 bcm2835: Add Raspberry Pi CPU frequency control to the device tree
Quoted 10 lines · Lubomir Rintel
This adds a device tree binding for Broadcom BCM2834 CPU frequency control driven via Raspberry Pi VideoCore 4 firmware interface.
Signed-off-by Lubomir Rintel <[email protected]>Cc Stephen Warren <[email protected]>Cc Lee Jones <[email protected]>Cc Eric Anholt <[email protected]>Cc linux-rpi-kernel at lists.infradead.orgCc linux-arm-kernel at lists.infradead.orgCc linux-pm at vger.kernel.org
Quoted 4 lines
---
Depends on the RPi Firmware driver submitted on linux-rpi-kernel a while ago. Can't see it in arm-soc or linux-next yet though (?). Available in branch 'rpi-firmware' of https://github.com/anholt/linux
Looks like the firmware driver slipped through the cracks for 4.3. I'll be sending a pull request for it for 4.4.
With the cprman clock driver, we could set CPU frequency natively from Linux. What we get from doing things through the VPU right now are that the MAX (overclock) setting can be set by the user in config.txt, and the VPU does some watching of thermals to decide when to throttle back to non-overclock.
Unless we do native thermal control from Linux (which we don't have a
driver for) to get equivalent protection, then I think we should
probably go ahead with the VPU-based cpufreq control.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151014/8c285a51/attachment-0001.sig>
PATCH 1/1 bcm2835: Add Raspberry Pi CPU frequency control to the device tree
In reply to Lubomir RintelQuoted 2 lines · Lubomir Rintel
This adds a device tree binding for Broadcom BCM2834 CPU frequency control driven via Raspberry Pi VideoCore 4 firmware interface.
Oh I see; that DT binding was sent as a separate patch rather than part of the series...
DT bindings patches need to be sent to the people/lists in the following MAINTAINERS entry:
OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
M: Rob Herring <[email protected]> M: Pawel Moll <[email protected]> M: Mark Rutland <[email protected]> M: Ian Campbell <[email protected]> M: Kumar Gala <[email protected]> L: devicetree at vger.kernel.org
Documentation/devicetree/bindings/cpufreq/raspberrypi,bcm2835-cpufreq.txt line 6
Quoted 12 lines
Documentation/devicetree/bindings/cpufreq/raspberrypi,bcm2835-cpufreq.txt new file +6
-0@@ -0,0 +1,13 @@ +Raspberry Pi Broadcom BCM2835 CPU frequency control + +Required properties: + +- compatible : should be "raspberrypi,bcm2835-cpufreq" +- firmware : the Raspberry Pi firmware node
It'd be best practice to mention the filename of the binding that defines the firmware. For example:
- firmware : phandle of the Raspberry Pi firmware node, as defined in .././arm/bcm/raspberrypi,bcm2835-firmware.txt.
That said, I'm not convinced cpufreq scaling should rely on the firmware directly, but instead should use the clock API to manipulate the clock.