On Thu, Feb 13, 2020 at 3:57 PM Nicolas Boichat drinkcat@chromium.org wrote:
[snip] But then there's a slight problem: panfrost_devfreq uses a bunch of clk_get_rate calls, and the clock PLLs (at least on MTK platform) are never fully precise, so we get back 299999955 for 300 Mhz and 799999878 for 800 Mhz. That means that the kernel is unable to keep devfreq stats as neither of these values are in the table: [ 4802.470952] devfreq devfreq1: Couldn't update frequency transition information. The kbase driver fixes this by remembering the last set frequency, and reporting that to devfreq. Should we do that as well or is there a better fix?
This one is my bad, I was missing this patch in my forklift to 4.19: 22bd4df9dadf46f drm/panfrost: devfreq: Round frequencies to OPPs
(should really try to boot that board on linux-next, but that's for another time)