On Wed, Jan 17, 2024 at 09:15:40PM +0100, Konrad Dybcio wrote: > > > On 1/17/24 18:34, Sibi Sankar wrote: > > From: Shivnandan Kumar <quic_kshivnan@xxxxxxxxxxx> > > Hi, a few early remarks, I am gonna look at this better next week. > > SCMI QCOM vendor protocol provides interface to communicate with SCMI > > controller and enable vendor specific features like bus scaling capable > > of running on it. > > "QCOM protocol" sounds overly generic, especially given how many > different vendor protocols have historically been present in > QC firmware.. > I was going to raise the same point :D, usually the name identifies the aim of the protocol (and the vendor also in this case) > > > > Signed-off-by: Shivnandan Kumar <quic_kshivnan@xxxxxxxxxxx> > > Co-developed-by: Ramakrishna Gottimukkula <quic_rgottimu@xxxxxxxxxxx> > > Signed-off-by: Ramakrishna Gottimukkula <quic_rgottimu@xxxxxxxxxxx> > > Co-developed-by: Amir Vajid <avajid@xxxxxxxxxxx> > > Signed-off-by: Amir Vajid <avajid@xxxxxxxxxxx> > > Co-developed-by: Sibi Sankar <quic_sibis@xxxxxxxxxxx> > > Signed-off-by: Sibi Sankar <quic_sibis@xxxxxxxxxxx> > > --- > > So, this is another 0x80 protocol, different to the one that has > been shipping on devices that got released with msm-5.4, msm-5.10 > and msm-5.15 [1][2]. They're totally incompatible (judging by the > msg format), use the same protocol ID and they are (at a glance) > providing access to the same HW/FW/tunables. > > I'm not sure if this can be trusted not to change again.. Unless > we get a strong commitment that all platforms (compute, mobile, > auto, iot, whatever) stick to this one.. > > That said, the spec (DEN0056C) says that protocol IDs 0x80-0xff > are: "Reserved for vendor or platform-specific extensions to > this interface.". So if perhaps there's a will to maintain > multiple versions of this, with a way to discern between them.. > Just recently we had a discussion with some other vendor about this possible clashing of vendor protocols numbers between different vendors/platforms, especially if aiming to just push all in defconfig. The basic idea to solve this, which I am going to post shortly in the next weeks, was to add a way to define and register your protocol number associated with a vendor identifier(s) of some kind, since vendor/subvendor/firmware versions are advertised by the Platform and are retrieved via Base protocol at probe time upfront; this way it 'should' be feasible to compile in any existent vendor protocol but allow at run-time only the registration with the SCMI core of the protocols whose vendor identity matches that of the identity advertised by the running firmware.... ...still not sure which of the IDs to use vendor/subvendor and still not have really experimented with this...so any feedback welcome. This would rule out, anyway, the capability of solving number clashes within the same vendor. Thanks, Cristian
