On 21.03.23 16:11, Konrad Dybcio wrote:
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?
That's a good question. From what i recall, i expect them to persist until
you reset the board. Probably we can verify it with an experiment by reading
them back, but let me check if i can find some info.
Thanks,
Georgi
