All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Sibi Sankar <quic_sibis@quicinc.com>
Cc: andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	robh+dt@kernel.org, cristian.marussi@arm.com, 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, Souvik.Chakravarty@arm.com,
	Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [RFC 1/2] dt-bindings: firmware: arm,scmi: Add support for memlat vendor protocol
Date: Thu, 3 Nov 2022 10:19:11 +0000	[thread overview]
Message-ID: <20221103101911.2qr3cla5mm4ctoe3@bogus> (raw)
In-Reply-To: <1667451512-9655-2-git-send-email-quic_sibis@quicinc.com>

On Thu, Nov 03, 2022 at 10:28:31AM +0530, Sibi Sankar wrote:
> Add bindings support for the SCMI QTI memlat (memory latency) vendor
> protocol. The memlat vendor protocol enables the frequency scaling of
> various buses (L3/LLCC/DDR) based on the memory latency governor
> running on the CPUSS Control Processor.
> 
> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
> ---
>  .../devicetree/bindings/firmware/arm,scmi.yaml     | 164 +++++++++++++++++++++
>  1 file changed, 164 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index 1c0388da6721..efc8a5a8bffe 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -189,6 +189,47 @@ properties:
>        reg:
>          const: 0x18
>  
> +  protocol@80:
> +    type: object
> +    properties:
> +      reg:
> +        const: 0x80
> +
> +      qcom,bus-type:
> +        $ref: /schemas/types.yaml#/definitions/uint32-array
> +        items:
> +          minItems: 1
> +        description:
> +          Identifier of the bus type to be scaled by the memlat protocol.
> +

Why is this part of the provider of the service ?

> +      cpu-map:
> +        type: object
> +        description:
> +          The list of all cpu cluster configurations to be tracked by the memlat protocol
> +
> +        patternProperties:
> +          '^cluster[0-9]':
> +            type: object
> +            description:
> +              Each cluster node describes the frequency domain associated with the
> +              CPUFREQ HW engine and bandwidth requirements of the buses to be scaled.
> +
> +            properties:
> +              operating-points-v2: true
> +
> +              qcom,freq-domain:
> +                $ref: /schemas/types.yaml#/definitions/phandle-array
> +                description:
> +                  Reference to the frequency domain of the CPUFREQ HW engine
> +                items:
> +                  - items:
> +                      - description: phandle to CPUFREQ HW engine
> +                      - description: frequency domain associated with the cluster
> +
> +            required:
> +              - qcom,freq-domain
> +              - operating-points-v2
> +

I would avoid all these here as part of provider node. It should be part
of the consumer to have all these details and do what it needs to do with
any such information.

-- 
Regards,
Sudeep

  reply	other threads:[~2022-11-03 10:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03  4:58 [RFC 0/2] Add support for SCMI QTI Memlat Vendor Protocol Sibi Sankar
2022-11-03  4:58 ` [RFC 1/2] dt-bindings: firmware: arm,scmi: Add support for memlat vendor protocol Sibi Sankar
2022-11-03 10:19   ` Sudeep Holla [this message]
2022-11-03 12:35   ` Rob Herring
2022-11-04 18:03   ` Rob Herring
2022-11-08 10:48     ` Sibi Sankar
2022-11-03  4:58 ` [RFC 2/2] firmware: arm_scmi: Add SCMI QTI Memlat " Sibi Sankar
2022-11-03 10:24   ` Sudeep Holla
2022-11-03 10:37     ` Sudeep Holla
2022-11-09  7:12       ` Sibi Sankar
2022-11-03 20:02   ` Matthias Kaehlcke
2022-11-08 11:06     ` Sibi Sankar
2022-11-03  9:41 ` [RFC 0/2] Add support for SCMI QTI Memlat Vendor Protocol Cristian Marussi
2022-11-08 11:01   ` Sibi Sankar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221103101911.2qr3cla5mm4ctoe3@bogus \
    --to=sudeep.holla@arm.com \
    --cc=Souvik.Chakravarty@arm.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_avajid@quicinc.com \
    --cc=quic_sibis@quicinc.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.