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. > > - Raspberry Pi's boot and other internal operations are operated by a firmware > running in it's VPU/GPU (called Video Core 4). > > - Even though Raspberry Pi exports it's clock registers, we're unable to modify > them as we could clash with the firmware. Messing around with clocks behind > the firmware's back would potentially void the board's warranty or even break > it. So we're stuck using a firmware frequency scaling interface the board > provides. > > - Some peripherals depend on VPU's clock (I2C, SPI, UART, ...). This clock is > updated by the firmware interface whenever we scale the frequency. Ok. Got it. > > - A solution would be to set all these clocks as non cachable, and alert the > peripherals through the clock notifier before and after the frequency scaling > happens. This way they could reprogram their dividers. It would be triggered > through a custom cpufreq driver that, with the knowledge of the possible VPU > frequencies, will pre-notify the peripherals, trigger the frequency scaling > and post-notify the peripherals. In order to achieve this, I figured I need > to create an exported version of __clk_notify(), which would trigger > notifications both for the provided clock and it's children. > > In principle, would it be acceptable to export the function? Any alternatives? I don't think we want to export __clk_notify(). If anything we've been trying to slowly remove the notifier chains that the clk framework implements, so exporting it would be going in the wrong direction. > > 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. After that's in place, I recommend that the downstream/child device drivers using clks that are children of the VPU clk migrate to clk_rate_exclusive_get() and clk_set_rate_exclusive() APIs. Once all the child clks are "owning" the rate they want their clks to be at, then we need to fix the clk framework rate setting code-path to let the parent VPU clk change rates from CPUfreq and work out how to achieve the "exclusive", i.e. "locked", rates for the children. If we do that then we should be in good shape and we can let the VPU clk change rate while maintaining the child clk rates for devices like UART, i2c, etc.