Hi Cristian,
On Thu, Feb 27, 2025 at 11:48:51AM +0000, Cristian Marussi wrote:
>On Wed, Feb 26, 2025 at 05:44:56PM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@xxxxxxx>
>>
>> Add compatible string for the protocols by adding new nodes
>> The current nodename pattern is "protocol@[0-9a-f]+$", the new node
>
>Hi Peng,
>
>> name will be "scmi-[a-z\-]+$".
>> With compatible string and new nodename, cpufreq and devfreq could be
>> separated into two nodes. And fwdevlink could correctly link suppliers
>> and consumers.
>
>beside the backward compatibility issues that Rob mentioned, the thing
>that worries me most is that, while the current bindings describe the
>SCMI protocols because the protocols are WHAT the platform FW exposes
>(and that is all that is needed by drivers to refer to a protocol and
>its resources)...here you are getting rid of all of this, and moving to
>describe basically the various devices that will use a protocol,
>potentially the same protocol, just to have a distinct fw_node ...
>(...I mean my understanding is that there wont be any protocol nodes
>left when the scmi- variant are present and, once, somehow, we will
>have transitioned into this...right ?)
>
>I haven't really had the time to go through properly your proposed
>solution to understand fully all its possible side-effects and how
>many SCMI features could be destroyed by removing protocol nodes
>descriptor as a whole...but...off the top of my head, as a quick
>example, how you will define a per-protocol dedicated transport
>channel in this new scenario ?
This is an issue for current RFC.
>...because You wont have anymore a protocol descriptor where to fit
>this AND you could have multiple DT nodes describing drivers that use
>that SAME protocol, so using this new nodes to fit the same
>transport-chan descriptors wont be possible either....
The other alternative would be
protocol@abc {
//
current property not change.
// Add two new optional subnodes
cpufreq {
compatible = "arm,scmi-cpufreq";
};
devfreq {
compatible = "arm,scmi-devfreq";
};
};
protocol@abc {
//
current property not change.
//add a new optional compatible
compatible = "arm,scmi-pinctrl";
};
If compatible exists, the driver could use compatible to match.
>
>IOW, sincerely, I understand you want to resolve the problem with
>fw_devlink (me too), but nuking down everything, while loosing, possibly,
>a number of the existing functionalities of the SCMI stack just to make
>it work with fw_devlink at all cost it does not seem to me an acceptable
>trade-off...
>
>...killing the whole existing protocols descriptors structure seems to
>me a recipe for disaster, also because, it just goes against the very
>essence of the objects that the FW exposes and the bindings can describe:
no. I was trying to bring backwards compatible solution.
If compatible is there, use compatible. If no compatible, still use reg.
>as an example, the SCMI platform server manage and exposes PERF_PROTOCOL
>and its related DOMAINS (all fully discoverable without any bindings),
>so, THAT is what is described in the bindings and referred by SCMI driver
>users: SCMI FW does NOT handle/expose TWO distinct perf devices, like the
>cpufreq/devfreq-device that you are trying to describe...
I understand, fw only provides one interface, but linux use two distinct
drivers. But this depends on how to abstract the interface for OS usage.
The interface supports CPU freq scaling and peripherals freq scaling,
I think it should be ok to add one node for each, as below:
protocol@xx {
cpufreq {}
devfreq {}
}
Thanks,
Peng
>
>As Sudeep mentioned, IMHO this seems mostly an *unsolved* implementation
>problem more than an actual issue with the bindings and how we describe
>SCMI resources that we need to refer to..
>
>> With compatible string, and driver updated.
>> - Differnet vendor drivers with same SCMI protocol ID could be built in
>> without concerning vendor A's driver got probed when using vendor B's
>> SoC
>
>as said, this is a corner case that is easily solvable with the current
>layout (and I will post a patch soon-ish to addess this...)
>
>> - NXP scmi pinctrl and ARM scmi pinctrl could be both built in, without
>> concerning arm scmi platform takes nxp scmi pinctrl node as supplier.
>>
>
>..the only real issue is the general fw_devlink issue as in cpufreq vs
>devfreq...
Not sure iiodev or thermal has same issue or not.
>
>Thanks,
>Cristian
