Message ID | 1667451512-9655-1-git-send-email-quic_sibis@quicinc.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp322413wru; Wed, 2 Nov 2022 22:01:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5zWZ9vlu+0Jx7Qpz3YFiOfzcN8vhT7jaH5O+3zWVH8sDUEtRcSbfjMFZeLVLayE8GBMXKN X-Received: by 2002:a65:6bc4:0:b0:439:8ff8:e2e1 with SMTP id e4-20020a656bc4000000b004398ff8e2e1mr24618299pgw.91.1667451705720; Wed, 02 Nov 2022 22:01:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667451705; cv=none; d=google.com; s=arc-20160816; b=dp5LsQ6HsIfroyc4t0o2P7EyDCQfpUWo6TRhUCI5468fq8daHfBU/KyC9Rb/sq2yG6 gp2ZIc7hWPOeJXp8ckql8fNB7MVM32ivyQCFneNQjy4G7pgMqOazaSqj9vG+mdX7gcYW LXzpWwui/5W5bF4PX/fGEK77eLkXBV/KFE4p+DYlHWCTAsEi8LofnLM15I0pZQfW8HzT fLPHXxwdYdQfyxd2S857gFRMa+xxD5E6rvfekuq5HYAit9xW2o8Bfi2oL3d2sQWi08v6 nmNVvIRnXoS38gVvVGGrciDvMzcovlLfphh0a65WGwHainzfJ0GvsAcWGSSmXGFLoZz7 GDow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=pzAfUujfgyx2soS+jvSWnljo9EBbCo8FnhU0j8z3GiM=; b=lKPfMn1S8nlT/6l+UOpRdTB69ZBis2wA0BamtU5EZbYTRnS3IlCQUHqW3wYAzEXQUi S07IENMRv/TLbj+lmmc9/IJq9y/Xpm0t4dKNOjogEpYcBSe5WSnW2wQRcro0Q3tjyKz+ kpixl0+of1q0t6VSPd+JNYfeai4zykCLaGd0Yq00in3mk0ubXW7wVn10kIXb9AXPWpbk Sti2J/duP5+lyrehTQ5ZVfWL8wnvx0z2RQoKYZ5eqqwOFsHcKLj5S+VsC4e8kWndwvIk 7IV9NzjhNLpSO4/DIBAqJ5F3nOJtkS+N/N0YD3reSsR4oaGFX7mpf84K/Y3kdk+fhOK/ GBOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=WzvkdtSB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r21-20020a63fc55000000b0044b014c9a3asi18280259pgk.300.2022.11.02.22.01.32; Wed, 02 Nov 2022 22:01:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=WzvkdtSB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229708AbiKCE73 (ORCPT <rfc822;yves.mi.zy@gmail.com> + 99 others); Thu, 3 Nov 2022 00:59:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbiKCE71 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Nov 2022 00:59:27 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2BB817E1E; Wed, 2 Nov 2022 21:59:24 -0700 (PDT) Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2A34gIlJ002831; Thu, 3 Nov 2022 04:59:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : mime-version : content-type; s=qcppdkim1; bh=pzAfUujfgyx2soS+jvSWnljo9EBbCo8FnhU0j8z3GiM=; b=WzvkdtSB8dPNHTZycpB5FHYs2F6opz3brP1sjeZCh3qXzBK8b128wk7ET6xF+28MJL7G BJsEdGrgKmCGOASkgPRp0hsiGDyTRGD5HpunuJvRInloEX/9d2bvn6kSfq7Jr32zdZyE rr9t2CDSxniZJ1QP6e4xmgMvuOBK2MvoP3IEHJ84+To/8O7hBftjr+OX83iQDEqDF80h zpOT18ij1grT06ndIJVcAPBx5peS5mcs6bfwofuRs7oVHxEt0EeoWbR567hzmxREmwTH PkVjSgNvYKkLcVTRSBj4t05prFaWnaXZPT6E0iifgmyp1NACpNEc/M8dAF6luGQQP8NG Yw== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3km6tnr2fc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Nov 2022 04:59:14 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 2A34xDrq000688 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Nov 2022 04:59:13 GMT Received: from blr-ubuntu-87.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Wed, 2 Nov 2022 21:59:10 -0700 From: Sibi Sankar <quic_sibis@quicinc.com> To: <andersson@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <robh+dt@kernel.org>, <sudeep.holla@arm.com>, <cristian.marussi@arm.com> CC: <agross@kernel.org>, <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <konrad.dybcio@somainline.org>, <quic_avajid@quicinc.com>, Sibi Sankar <quic_sibis@quicinc.com> Subject: [RFC 0/2] Add support for SCMI QTI Memlat Vendor Protocol Date: Thu, 3 Nov 2022 10:28:30 +0530 Message-ID: <1667451512-9655-1-git-send-email-quic_sibis@quicinc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: 72A2vlz4NC6tNXzgA4pkOPkaGRBHslF0 X-Proofpoint-ORIG-GUID: 72A2vlz4NC6tNXzgA4pkOPkaGRBHslF0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-02_15,2022-11-02_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=812 priorityscore=1501 lowpriorityscore=0 spamscore=0 mlxscore=0 bulkscore=0 impostorscore=0 suspectscore=0 adultscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211030035 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748449839719277127?= X-GMAIL-MSGID: =?utf-8?q?1748449839719277127?= |
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
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 > > >