The SCMI QCOM vendor protocol provides a generic way of exposing a number of Qualcomm SoC specific features (like memory bus scaling) through a mixture of pre-determined algorithm strings and param_id pairs hosted on the SCMI controller. Introduce a client driver that uses the memlat algorithm string hosted on QCOM SCMI Vendor Protocol to detect memory latency workloads and control frequency/level of the various memory buses (DDR/LLCC/DDR_QOS). Generic QCOM Vendor protocol background: It was found that a lot of the vendor protocol used internally was for debug/internal development purposes that would either be super SoC specific or had to be disabled because of some features being fused during production. This lead to a large number of vendor protocol numbers being quickly consumed and were never released either. Using a generic vendor protocol with functionality abstracted behind algorithm strings gave us the flexibility of allowing such functionality exist during initial development/debugging while still being able to expose functionality like memlat once they have matured enough. The param-ids are certainly expected to act as ABI for algorithms strings like MEMLAT. Now that the SCMI controller firmware (CPUCP) is feature complete with the impending release of X1E SoCs, I should be able to get out next re-spins a lot quicker. I'll keep adding more documentation in the subsequent re-spins. Thanks in advance for taking time to review the series. Opens: * opp-tables are used but they don't get to be added to the scmi device (thus we rely on a lot of manual parsing) because the memlat client driver doesn't vote on these resources clocks/interconnects/power-domain from the kernel and some of the resouces aren't modelled in the first place like DDR_QOS. V1: * Add missing bindings for the protocol. [Konrad/Dmitry] * Use alternate bindings. [Dmitry/Konrad] * Rebase on top of Cristian's "SCMI multiple vendor protocol support" series. [Cristian] * Add more documentation wherever possible. [Sudeep] * Replace pr_err/info with it's dev equivalents. * Mixed tabs and initialization cleanups in the memlat driver. [Konrad] * Commit message update for the memlat driver. [Dmitry] * Cleanups/Fixes suggested for the client driver. [Dmitry/Konrad/Cristian] * Use opp-tables instead of memfreq-tbl. [Dmitry/Konrad] * Detect physical cpu to deal with variants with reduced cpu count. * Add support for DDR_QOS mem_type. To Dos: * More documentation [Sudeep/Dmitry/Konrad] * Use alternate bindings instead of freq-table-Hz. [Dmitry] * Prevent duplication of code using vendor protocol driver. [Dmitry] Depends on: vendor protocol submenu: https://lore.kernel.org/all/20240408093052.3801576-3-cristian.marussi@xxxxxxx/ X1E cpufreq: https://lore.kernel.org/lkml/20240612124056.39230-1-quic_sibis@xxxxxxxxxxx/ Sibi Sankar (4): dt-bindings: firmware: Add support for QCOM Vendor Protocol firmware: arm_scmi: vendors: Add QCOM vendor protocol soc: qcom: Introduce SCMI based Memlat (Memory Latency) governor arm64: dts: qcom: x1e80100: Enable LLCC/DDR/DDR_QOS dvfs .../bindings/firmware/arm,scmi.yaml | 21 + .../bindings/soc/qcom/qcom,scmi-memlat.yaml | 243 ++++++++ arch/arm64/boot/dts/qcom/x1e80100.dtsi | 136 ++++ drivers/firmware/arm_scmi/vendors/Kconfig | 12 + drivers/firmware/arm_scmi/vendors/Makefile | 2 +- .../arm_scmi/vendors/qcom_scmi_vendor.c | 184 ++++++ drivers/soc/qcom/Kconfig | 12 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/qcom_scmi_client.c | 590 ++++++++++++++++++ include/dt-bindings/soc/qcom,scmi-vendor.h | 22 + include/linux/qcom_scmi_vendor.h | 39 ++ 11 files changed, 1261 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,scmi-memlat.yaml create mode 100644 drivers/firmware/arm_scmi/vendors/qcom_scmi_vendor.c create mode 100644 drivers/soc/qcom/qcom_scmi_client.c create mode 100644 include/dt-bindings/soc/qcom,scmi-vendor.h create mode 100644 include/linux/qcom_scmi_vendor.h -- 2.34.1
