Message ID | 20240604011157.2358019-1-quic_sibis@quicinc.com |
---|---|
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/