Stephen Boyd writes: > Quoting Nicolas Saenz Julienne (2019-04-11 10:43:22) >> Hi, >> I'm working on implementing proper cpufreq support for Raspberry Pi and stumbled >> upon an issue I'd like your opinion on: > > You may want to work with Eric. I think Eric has been looking at > Raspberry Pi clk things from what I can recall. Sorry for the delay, I've been busy with the switch to my new job. I haven't been doing much with the clocks recently, but hopefully I can shed some light. >> Note that cpufreq notifiers are not an option as they provide the CPU clock >> change rates which are useless to the peripherals. Also note that the >> peripherals need to know the clock rate change in advance. >> > > How does it work today? Do the peripherals set clk rates under the > assumption that the parent of the clk they're dealing with (I guess VPU > clk?) isn't going to change rate? > > If that's right then I see two pitfalls. The first is that we probably > want to maintain the frequency of those child clks when the VPU clk > changes rate. The second is that we should integrate the VPU clk into > the clk framework so that when it changes rate, the new frequency > propagates down to the child clks. It could still use the firmware > interface to change the VPU clk in the clk provider driver. I suppose > cpufreq-dt could be layered on top of the VPU clk too so that it all > just becomes a clk tree management problem. Linux doesn't drive changing the VPU clock. It's controlled by the firmware's turbo/undervoltage/temperature management thread, and the Foundation wants to keep it that way, unfortunately (that way all devices have the same temperature management, rather than relying on the OS's behavior). We do expose the VPU (aka bus or core) clock in upstream Linux, but if you try to read its rate you just get some sample. Don't try propagating a rate change through VPU clock, it will not go well (Linux doesn't control all the leaf clocks, so it would just be flipping whose clocks get screwed up by rate changes, and you'd be racing the firmware's thread). Right now in the downstream tree they set up the peripherals using the best-case core clock, so things only get clocked down from there: commit 6239f614fa5ac3893465f71738e031ee175be14b Author: Phil Elwell Date: Mon Mar 6 09:06:18 2017 +0000 clk-bcm2835: Read max core clock from firmware The VPU is responsible for managing the core clock, usually under direction from the bcm2835-cpufreq driver but not via the clk-bcm2835 driver. Since the core frequency can change without warning, it is safer to report the maximum clock rate to users of the core clock - I2C, SPI and the mini UART - to err on the safe side when calculating clock divisors. If the DT node for the clock driver includes a reference to the firmware node, use the firmware API to query the maximum core clock instead of reading the divider registers. Prior to this patch, a "100KHz" I2C bus was sometimes clocked at about 160KHz. In particular, switching to the 4.9 kernel was likely to break SenseHAT usage on a Pi3. Signed-off-by: Phil Elwell