On 21.03.2023 14:58, Georgi Djakov wrote: > Hi, > > On 11.03.23 17:26, Dmitry Baryshkov wrote: >> On 11/03/2023 16:38, Bryan O'Donoghue wrote: >>> On 11/03/2023 14:35, Dmitry Baryshkov wrote: >>>>> Its probably worthwhile experimenting to see if the*ufs*_clk can/should >>>>> be added to the UFS device list of clocks. >>>> While we were doing this for some of the clocks (PCIe and USB, if I'm >>>> not mistaken), I think that generally this is not fully correct. In my >>>> opinion it should be in the interconnect driver, who turns >>>> corresponding clocks on and off. These clocks correspond to the SoC >>>> topology, rather than the end-device. >>>> >>> >>> True enough, they are interconnect clocks. >>> >>> The question is how to only turn them on when the device that depends on them wants them. >> >> I think we can turn them on an off from qcom_icc_set(). Each node can list required clocks. >> > > Yes, this is a bit weird, but looks like these are the interface clocks > required for programming the qos box of the respective peripheral and > nothing else. Maybe we can even configure QoS just once (eg. on the first > bandwidth request) and not every time we call qcom_icc_set(). Would that persist a full bus reset - if we e.g. shut down MMNoC after the display stack is turned off in preparation for a power collapse, would we have to reprogram it? Another thing is, do we know "how persistent" the QoS settings are? What could reset them? Would a bandwidth request for a node that belongs to the same path do so? Konrad > > BR, > Georgi
