So, I decided to add additional opps to the opp-table-cci as I wanted to have additional frequencies on the cluster0 opp-table and may have come across a bug in the cci devfreq driver
The CCI devfreq driver passes the raw requested frequency (*freq) to the clock framework, but it does not update *freq after calling devfreq_recommended_opp(). As a result, when the passive governor requests a non-OPP-aligned rate (e.g. 1017600000 Hz), the OPP layer rounds it to the nearest valid OPP, but *freq is left unchanged.
Devfreq core then receives transitional or non-OPP frequencies and fails to find them in the freq_table, producing repeated warnings:
devfreq cci: Couldn't update frequency transition information.
Debug created for the purpose of identifying the problem info shows [ 305.794363] devfreq cci: DEBUG: previous_freq=1080000000 new_freq=40000000 [ 305.880502] devfreq cci: DEBUG: previous_freq=40000000 new_freq=1017600000 [ 305.962686] devfreq cci: update_status: new_freq=1017600000 not in table [ 306.042785] devfreq cci: Couldn’t update frequency transition information. [ 306.128581]
here are the commit details
The issue only happens if using schedutil or ondemand governors. As the platform uses userspace by default it may have been the reason why hasn’t been found.
Also, there were opps-cci missing … this is the updated cci opp table
cci_opp: opp-table-cci {
compatible = "operating-points-v2";
opp-shared;
opp-40000000 {
opp-hz = /bits/ 64 <40000000>;
opp-microvolt = <850000>;
};
opp-480000000 {
opp-hz = /bits/ 64 <480000000>;
opp-microvolt = <850000>;
};
opp-660000000 {
opp-hz = /bits/ 64 <660000000>;
opp-microvolt = <850000>;
};
opp-830400000 {
opp-hz = /bits/ 64 <830400000>;
opp-microvolt = <850000>;
};
opp-900000000 {
opp-hz = /bits/ 64 <900000000>;
opp-microvolt = <850000>;
};
opp-1080000000 {
opp-hz = /bits/ 64 <1080000000>;
opp-microvolt = <900000>;
};
};