[RFC,0/2] Add support for SCMI QTI Memlat Vendor Protocol

Message ID 1667451512-9655-1-git-send-email-quic_sibis@quicinc.com
Headers
Series Add support for SCMI QTI Memlat Vendor Protocol |

Message

Sibi Sankar Nov. 3, 2022, 4:58 a.m. UTC
  The patch series documents the bindings and adds support for the
SCMI QTI memlat (memory latency) vendor protocol. The protocol takes
in several tuneables including the IPM ratio (Instructions Per Miss),
bus bandwidth requirements and PMU maps to enable frequency scaling
of various buses (L3/LLCC/DDR). The scaling is performed by the HW
memory latency governor running on the CPUSS Control Processor.

Depends on CPUCP mailbox driver:
https://patchwork.kernel.org/project/linux-arm-msm/cover/1663135386-26270-1-git-send-email-quic_sibis@quicinc.com/

Sibi Sankar (2):
  dt-bindings: firmware: arm,scmi: Add support for memlat vendor
    protocol
  firmware: arm_scmi: Add SCMI QTI Memlat vendor protocol

 .../devicetree/bindings/firmware/arm,scmi.yaml     | 164 +++++++++++++
 drivers/firmware/arm_scmi/Kconfig                  |  10 +
 drivers/firmware/arm_scmi/Makefile                 |   1 +
 drivers/firmware/arm_scmi/qcom_memlat_vendor.c     | 269 +++++++++++++++++++++
 include/linux/scmi_protocol.h                      |  36 +++
 5 files changed, 480 insertions(+)
 create mode 100644 drivers/firmware/arm_scmi/qcom_memlat_vendor.c
  

Comments

Cristian Marussi Nov. 3, 2022, 9:41 a.m. UTC | #1
On Thu, Nov 03, 2022 at 10:28:30AM +0530, Sibi Sankar wrote:
> The patch series documents the bindings and adds support for the
> SCMI QTI memlat (memory latency) vendor protocol. The protocol takes
> in several tuneables including the IPM ratio (Instructions Per Miss),
> bus bandwidth requirements and PMU maps to enable frequency scaling
> of various buses (L3/LLCC/DDR). The scaling is performed by the HW
> memory latency governor running on the CPUSS Control Processor.
> 
> Depends on CPUCP mailbox driver:
> https://patchwork.kernel.org/project/linux-arm-msm/cover/1663135386-26270-1-git-send-email-quic_sibis@quicinc.com/
> 

[+ CC: souvik.chakravarty@arm.com ]

Hi Sibi,

Nice to see vendor protocols starting to make their way into upstream !

I only glanced through the series as of now, and I'd have a few
questions before going on with the review:

 - why this protocol is dependent on a specific transport ?
   Is it to compile it only on platform supoprting it without adding
   a per-protocol Kconfig ?

Protocols are anyway enumerated at SCMI stack probe time so even if it
is not there it just won't be activated...I maybe missing something.

Thanks,
Cristian
  
Sibi Sankar Nov. 8, 2022, 11:01 a.m. UTC | #2
Hey Cristian,
Thanks for taking time to review the series.

On 11/3/22 15:11, Cristian Marussi wrote:
> On Thu, Nov 03, 2022 at 10:28:30AM +0530, Sibi Sankar wrote:
>> The patch series documents the bindings and adds support for the
>> SCMI QTI memlat (memory latency) vendor protocol. The protocol takes
>> in several tuneables including the IPM ratio (Instructions Per Miss),
>> bus bandwidth requirements and PMU maps to enable frequency scaling
>> of various buses (L3/LLCC/DDR). The scaling is performed by the HW
>> memory latency governor running on the CPUSS Control Processor.
>>
>> Depends on CPUCP mailbox driver:
>> https://patchwork.kernel.org/project/linux-arm-msm/cover/1663135386-26270-1-git-send-email-quic_sibis@quicinc.com/
>>
> 
> [+ CC: souvik.chakravarty@arm.com ]
> 
> Hi Sibi,
> 
> Nice to see vendor protocols starting to make their way into upstream !
> 
> I only glanced through the series as of now, and I'd have a few
> questions before going on with the review:
> 
>   - why this protocol is dependent on a specific transport ?
>     Is it to compile it only on platform supoprting it without adding
>     a per-protocol Kconfig ?

It was done just to compile it on platforms supporting it but it doesn't
have to done that way. I remove the dependency during the next re-spin.

- Sibi

> 
> Protocols are anyway enumerated at SCMI stack probe time so even if it
> is not there it just won't be activated...I maybe missing something.
> 
> Thanks,
> Cristian
> 
> 
>