Messages in this thread | | | Date | Wed, 29 Jan 2020 19:51:59 +0530 | From | Sibi Sankar <> | Subject | Re: [RFC v3 00/10] DDR/L3 Scaling support on SDM845 and SC7180 SoCs |
| |
Hey Rob,
On 2020-01-29 08:24, Rob Clark wrote: > On Mon, Jan 27, 2020 at 12:05 PM Sibi Sankar <sibis@codeaurora.org> > wrote: >> >> This RFC series aims to extend cpu based scaling support to L3/DDR on >> SDM845 and SC7180 SoCs. >> >> Patches [1-3] - Blacklist SDM845 and SC7180 in cpufreq-dt-platdev >> Patches [5-7] - Hack in a way to add/remove multiple opp tables to >> a single device. I am yet to fix the debugfs to >> support multiple opp_tables per device but wanted to >> send what was working upstream to get an idea if >> multiple >> opp tables per device is a feature that will be useful >> upstream. >> Patches [9-10] - Add the cpu/cpu-ddr/cpu-l3 opp tables for SDM845 >> and SC7180 SoCs. >> >> v3: >> * Migrated to using Saravana's opp-kBps bindings [1] >> * Fixed some misc comments from Rajendra >> * Added support for SC7180 >> >> v2: >> * Incorporated Viresh's comments from: >> >> https://lore.kernel.org/lkml/20190410102429.r6j6brm5kspmqxc3@vireshk-i7/ >> >> https://lore.kernel.org/lkml/20190410112516.gnh77jcwawvld6et@vireshk-i7/ >> * Dropped cpufreq-map passive governor >> >> Git-branch: https://github.com/QuinAsura/linux/tree/lnext-012420 >> >> Some alternate ways of hosting the opp-tables: >> https://github.com/QuinAsura/linux/commit/50b92bfaadc8f9a0d1e12249646e018bd6d1a9d3 >> https://github.com/QuinAsura/linux/commit/3d23d1eefd16ae6d9e3ef91e93e78749d8844e98 >> Viresh didn't really like ^^ bindings and they dont really scale well. >> Just >> including them here for completeness. >> >> Depends on the following series: >> [1] https://patchwork.kernel.org/cover/11277199/ >> [2] https://patchwork.kernel.org/cover/11055499/ >> [3] https://patchwork.kernel.org/cover/11326381/ > > So drive-by question, from the perspective of someone who cares about > a non-cpu device that frequently enjoys a lot of bandwidth (ie. the > GPU).. any thoughts on how ddr scaling would/should work for workloads > where the CPU is not particularly busy?
I guess Jordan would have more info about ^^. From what I can see from the CAF trees there is a similar device freq -> DDR Freq mapping that you can achieve with required-opps bindings and a custom governor ;)
> > BR, > -R > >> >> Sibi Sankar (10): >> arm64: dts: qcom: sdm845: Add SoC compatible to MTP >> cpufreq: blacklist SDM845 in cpufreq-dt-platdev >> cpufreq: blacklist SC7180 in cpufreq-dt-platdev >> OPP: Add and export helper to update voltage >> opp: of: export _opp_of_get_opp_desc_node >> opp: Allow multiple opp_tables to be mapped to a single device >> opp: Remove multiple attached opp tables from a device >> cpufreq: qcom: Update the bandwidth levels on frequency change >> arm64: dts: qcom: sdm845: Add cpu OPP tables >> arm64: dts: qcom: sc7180: Add cpu OPP tables >> >> arch/arm64/boot/dts/qcom/sc7180.dtsi | 287 +++++++++++++++ >> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 2 +- >> arch/arm64/boot/dts/qcom/sdm845.dtsi | 453 >> ++++++++++++++++++++++++ >> drivers/cpufreq/cpufreq-dt-platdev.c | 2 + >> drivers/cpufreq/qcom-cpufreq-hw.c | 246 +++++++++++-- >> drivers/opp/core.c | 111 +++++- >> drivers/opp/of.c | 3 +- >> drivers/opp/opp.h | 2 + >> include/linux/pm_opp.h | 10 + >> 9 files changed, 1083 insertions(+), 33 deletions(-) >> >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >> Forum, >> a Linux Foundation Collaborative Project
-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
| |