On Thu, Jul 20, 2023 at 09:44:38AM -0700, Bart Van Assche wrote: > On 7/19/23 22:40, Manivannan Sadhasivam wrote: > > This series adds OPP (Operating Points) support to UFSHCD driver and > > interconnect support to Qcom UFS driver. > > > > Motivation behind adding OPP support is to scale both clocks as well as > > regulators/performance state dynamically. Currently, UFSHCD just scales > > clock frequency during runtime with the help of "freq-table-hz" property > > defined in devicetree. With the addition of OPP tables in devicetree (as > > done for Qcom SDM845 and SM8250 SoCs in this series) UFSHCD can now scale > > both clocks and performance state of power domain which helps in power > > saving. > > > > For the addition of OPP support to UFSHCD, there are changes required to > > the OPP framework and devfreq drivers which are also added in this series. > > > > Finally, interconnect support is added to Qcom UFS driver for scaling the > > interconnect path dynamically. This is required to avoid boot crash in > > recent SoCs and also to save power during runtime. More information is > > available in patch 13/13. > > How much power can OPP save? I'm asking this since I'm wondering whether > the power saved by OPP outweighs the complexity added by this patch series. > I haven't had a chance to do proper power measurements with this series due to lack of access to tools. But it won't be optimal to run the clocks at high/low frequencies without changing the associated regulator/power domain state. Atleast on Qcom platforms, the clock frequencies are tied to RPMh (power management entity) performance states for the peripherals. So both have to go hand in hand. Till now, only UFS among the other peripherals is not doing it right and hence this series. - Mani > Thanks, > > Bart. -- மணிவண்ணன் சதாசிவம்