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/

Sibi Sankar (4):
  dt-bindings: interconnect: qcom,msm8998-bwmon: Add X1E80100 BWMON
    instances
  soc: qcom: icc-bwmon: Allow for interrupts to be shared across
    instances
  arm64: dts: qcom: x1e80100: Add BWMONs
  arm64: dts: qcom: x1e80100: Add fastrpc nodes

 .../interconnect/qcom,msm8998-bwmon.yaml      |   2 +
 arch/arm64/boot/dts/qcom/x1e80100.dtsi        | 325 ++++++++++++++++++
 drivers/soc/qcom/icc-bwmon.c                  |   3 +-
 3 files changed, 329 insertions(+), 1 deletion(-)

-- 
2.34.1

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?

Konrad

[1] https://lore.kernel.org/all/20240117173458.2312669-1-quic_sibis@quicinc.com/

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).

-Sibi

> 
> Konrad
> 
> [1] https://lore.kernel.org/all/20240117173458.2312669-1-quic_sibis@quicinc.com/

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