devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC V3 0/4] arm_scmi: vendors: ARM SCMI Qualcomm Vendor Protocol
@ 2024-07-02 19:14 Sibi Sankar
  2024-07-02 19:14 ` [RFC V3 1/4] dt-bindings: firmware: Document bindings for ARM SCMI QCOM " Sibi Sankar
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Sibi Sankar @ 2024-07-02 19:14 UTC (permalink / raw)
  To: sudeep.holla, cristian.marussi, andersson, konrad.dybcio, robh+dt,
	krzysztof.kozlowski+dt
  Cc: linux-kernel, linux-arm-msm, devicetree, linux-arm-kernel,
	quic_rgottimu, quic_kshivnan, quic_sibis, conor+dt

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 out 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.

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 resources aren't modeled in the first place like DDR_QOS.

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]

V2:
* Drop container dvfs memlat container node. [Rob]
* Move scmi-memlat.yaml to protocol level given that a lot of vendors might end up
  using the same protocol number. [Rob]
* Replace qcom,cpulist with the standard "cpus" property. [Rob]
* Fix up compute-type/ipm-ceil required. [Rob]
* Make driver changes to the accommodate bindings changes. [Rob]
* Minor fixups in subjects/coverletter.
* Minor style fixes in dts.

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.

Sibi Sankar (4):
  dt-bindings: firmware: Document bindings for ARM SCMI QCOM Vendor
    Protocol
  firmware: arm_scmi: vendors: Add ARM SCMI QCOM vendor protocol v1.0
  soc: qcom: Introduce SCMI based Memlat (Memory Latency) governor
  arm64: dts: qcom: x1e80100: Enable LLCC/DDR/DDR_QOS dvfs

 .../bindings/firmware/arm,scmi.yaml           |  15 +
 .../bindings/soc/qcom/qcom,scmi-memlat.yaml   | 242 ++++++++
 arch/arm64/boot/dts/qcom/x1e80100.dtsi        | 138 +++++
 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           | 583 ++++++++++++++++++
 include/dt-bindings/soc/qcom,scmi-vendor.h    |  22 +
 include/linux/qcom_scmi_vendor.h              |  39 ++
 11 files changed, 1249 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


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2024-10-07  7:34 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-02 19:14 [RFC V3 0/4] arm_scmi: vendors: ARM SCMI Qualcomm Vendor Protocol Sibi Sankar
2024-07-02 19:14 ` [RFC V3 1/4] dt-bindings: firmware: Document bindings for ARM SCMI QCOM " Sibi Sankar
2024-07-09 16:32   ` Cristian Marussi
2024-07-11 13:31     ` Sibi Sankar
2024-07-02 19:14 ` [RFC V3 2/4] firmware: arm_scmi: vendors: Add ARM SCMI QCOM vendor protocol v1.0 Sibi Sankar
2024-07-09 10:10   ` Konrad Dybcio
2024-07-11 13:33     ` Sibi Sankar
2024-07-09 17:52   ` Cristian Marussi
2024-10-07  7:29     ` Sibi Sankar
2024-07-02 19:14 ` [RFC V3 3/4] soc: qcom: Introduce SCMI based Memlat (Memory Latency) governor Sibi Sankar
2024-07-03  8:44   ` Shivnandan Kumar
2024-07-03 11:34     ` Sibi Sankar
2024-07-09 10:51   ` Konrad Dybcio
2024-10-07  7:22     ` Sibi Sankar
2024-07-10 11:36   ` Cristian Marussi
2024-10-07  7:33     ` Sibi Sankar
2024-07-02 19:14 ` [RFC V3 4/4] arm64: dts: qcom: x1e80100: Enable LLCC/DDR/DDR_QOS dvfs Sibi Sankar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).