| Message ID | 20240604011157.2358019-1-quic_sibis@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: dts: qcom: x1e80100: Enable bwmon and fastrpc support | expand |
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
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(-)