Hi Viresh, On Wed, May 04, 2022 at 03:57:45PM +0530, Viresh Kumar wrote: > On 04-05-22, 16:51, Hector Martin wrote: > > Hi folks, > > > > Here's a second take on the cpufreq driver for Apple SoCs. This is a > > complete rewrite using a stand-alone cpufreq driver instead of using the > > cpufreq-dt infrastructure. > > > > Since v1 we ran some experiments on the memory controller performance > > switching and it turns out it doesn't make a huge difference, so it > > makes sense to punt that feature to the future (perhaps once a proper > > memory controller driver exists for other reasons, e.g. for error > > handling). > > > > One advantage of having a standalone cpufreq driver is that we can > > support fast switching. This also means any future interaction with > > the memory controller will probably use some bespoke mechanism instead > > of the genpd infrastructure, so we can keep the fast path without > > allowing sleeps/etc. > > > > The driver is based on scpi-cpufreq.c, with some bits (e.g. the > > apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it. > > I'm not sure if that particular property should be described > > in a binding, since it goes in the cpu nodes (qcom doesn't have it > > anywhere...). > > Hi Mani, > > I can see that Rob asked you to add this somewhere, maybe in arm/cpu > stuff, but I don't think you ever sent a patch with that. What > happened ? > > https://lore.kernel.org/lkml/20201013171800.GA3716411@bogus/ > Oops. Looks like that one slipped through the cracks. I did add it to my todo list for qcom-cpufreq but missed it completely. I will look into it. Thanks, Mani > -- > viresh
