> Date: Tue, 19 Nov 2024 22:03:01 +0100
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> 
> > Date: Tue, 19 Nov 2024 14:20:12 +0100
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > 
> > > Date: Mon, 18 Nov 2024 01:01:11 +0100
> > > From: Tobias Heider <tobias.heider@stusta.de>
> > > 
> > > Here is the promised diff to get scmi for cpu frequency management
> > > working on the Snapdragon X Elite.  Roughly speaking this adds two
> > > big new features: mailbox transport and the scmi perf protocol.
> > > 
> > > Mailbox transport is very similar to smc which we already support.
> > > Messages are written to a shared memory region, instead of an SMC call we
> > > use a mailbox doorbell to notify the platform that our request is ready.
> > > On X Elites this is done using the CPUCP mailbox which we support via
> > > qccpucp(4). The attach function for the mbox transport is deferred to make
> > > sure our mailbox driver is available when we need it.
> > > There are a lot of possible optimization here, instead of polling we could
> > > use mailbox interrupts and for PERFORMANCE_LEVEL_GET we probably want to
> > > switch to using a fast channel at some point.
> > > 
> > > The perf protocol allows us to read and set the performance level of our
> > > performance domains. On the X Elite we have 3 domains, each spanning 4 cpu
> > > cores. This patch adds sensors to expose the current frequency and power
> > > consumption for each domain. It is a bit pointless since the level doesn't
> > > really change currently. Eventually we probably want to hook this up to
> > > cpu(4) to expose it to apm(8).
> > > 
> > > The output on my T14s looks like this:
> > > $ sysctl | grep scmi                                                   
> > > hw.sensors.scmi0.power0=0.22 W
> > > hw.sensors.scmi0.power1=0.29 W
> > > hw.sensors.scmi0.power2=0.31 W
> > > hw.sensors.scmi0.frequency0=2976000000.00 Hz
> > > hw.sensors.scmi0.frequency1=3417600000.00 Hz
> > > hw.sensors.scmi0.frequency2=3417600000.00 Hz
> > > 
> > > Test feedback and reviews welcome. I don't have a machine using scmi-smc or
> > > the clock protocol so I'd appreciate if someone could test those too.
> > 
> > A first drive-by review.  I need to test this on some hardware that
> > implements scmi-smc before I give an ok.  But it basically looks ok.
> 
> The rk3588 isn't happy with this.  I'll investigate...

Turns out to be a simple typo:

> > > +
> > > +	if (OF_is_compatible(faa->fa_node, "arm,scmi-scm")) {
> > > +		scmi_attach_smc(sc, faa);

Should be "arm,scmi-smc".