On 1/17/24 18:34, Sibi Sankar wrote:
From: Shivnandan Kumar <quic_kshivnan@xxxxxxxxxxx> 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..
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.. Konrad [1] https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/KERNEL.PLATFORM.2.1.r5-05400-kernel.0/drivers/firmware/arm_scmi/memlat_vendor.c?ref_type=tags [2] https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/KERNEL.PLATFORM.2.1.r5-05400-kernel.0/include/linux/scmi_memlat.h#L16