[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7395f6ca-31d7-4ebc-b846-6c68e2ae2efe@linaro.org>
Date: Tue, 18 Jun 2024 16:39:06 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Sibi Sankar <quic_sibis@...cinc.com>, andersson@...nel.org,
djakov@...nel.org, robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
srinivas.kandagatla@...aro.org
Cc: linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
quic_rgottimu@...cinc.com, quic_kshivnan@...cinc.com, conor+dt@...nel.org,
dmitry.baryshkov@...aro.org, abel.vesa@...aro.org
Subject: Re: [PATCH 0/4] arm64: dts: qcom: x1e80100: Enable bwmon and fastrpc
support
On 6/13/24 19:27, Sibi Sankar wrote:
>
>
> On 6/6/24 16:00, Konrad Dybcio wrote:
>> On 4.06.2024 3:11 AM, Sibi Sankar wrote:
>>> This patch series enables bwmon and fastrpc support on X1E80100 SoCs.
>>>
>>> This series applies on:
>>> next-20240603 + https://lore.kernel.org/lkml/20240603205859.2212225-1-quic_sibis@quicinc.com/
>>>
>>
>> Going back to [1], is memlat-over-scmi not enough to give us good numbers
>> without OS intervention? Does probing bwmon and making some decisions in
>> Linux actually help here?
>
> Memlat and bwmon are meant to cover to different use cases. Though
> they have a big overlap on when they get triggered bwmon is specifically
> meant to address cases where band-width aggregation is required (meaning
> if other peripherals already have a avg bw vote on active LLCC/DDR, the
> vote from bwmon would be an additional request on top of that). However
> to make use of this we should vote for avg-kbps in addition to peak from
> icc-bwmon driver which we don't currently do (Shiv was planning on
> sending a fix for it).
Great, thanks for confirming
Konrad
Powered by blists - more mailing lists