On Tue, 1 Nov 2022 at 19:17, Hector Martin <marcan@xxxxxxxxx> wrote: > > On 02/11/2022 00.16, Ulf Hansson wrote: > > On Mon, 24 Oct 2022 at 06:40, Hector Martin <marcan@xxxxxxxxx> wrote: > >> > >> This driver implements CPU frequency scaling for Apple Silicon SoCs, > >> including M1 (t8103), M1 Max/Pro/Ultra (t600x), and M2 (t8112). > >> > >> Each CPU cluster has its own register set, and frequency management is > >> fully automated by the hardware; the driver only has to write one > >> register. There is boost frequency support, but the hardware will only > >> allow their use if only a subset of cores in a cluster are in > >> non-deep-idle. Since we don't support deep idle yet, these frequencies > >> are not achievable, but the driver supports them. They will remain > >> disabled in the device tree until deep idle is implemented, to avoid > >> confusing users. > > > > Out of curiosity, may I ask if this implies the need of a > > synchronization mechanism on the Linux side? Or is the boost frequency > > dynamically managed solely by HW/FW? > > It's managed by hardware - Linux gets to request whatever frequency it > wants, and the hardware will limit it to what is achievable given the > current idle states within the cluster (and it will change automatically > with them). So if Linux asks for 3.2 GHz but there are no deep idle > cores in the cluster, you get 3.0. If there's one deep idle core, you > get 3.1 (I think). Three, 3.2. So this driver doesn't have to do > anything (and will report the correct current-frequency as long as the > per-SoC compatible is matched; without that this feature is disabled and > it just reports the requested frequency). We could enable the boost > states today just fine, it's just that they would never actually be > reached by the hardware. Thanks for sharing these details. It's always nice to know a bit more about how the HW works! >From the reviewing point of view, I don't have more to add at this point! Kind regards Uffe
