Message ID | 1667451512-9655-1-git-send-email-quic_sibis@quicinc.com (mailing list archive) |
---|---|
Headers | show |
Series | Add support for SCMI QTI Memlat Vendor Protocol | expand |
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
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 > > >