Re: [PATCH v3 0/5] Refactor thermal pressure update to avoid code duplication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Lukasz,


I think I have figure out what is going on with the issue that
you've reported. On this rockchip platform you are probably using
step-wise thermal governor, which tries to decrease/increase
max allowed frequency step-by-step walking through the sorted
frequencies. So it would always set the thermal pressure to 0
when the thermal throttling is gone.
On the Qcom platform there is a different policy in HW/FW which
controls thermal and it can simple remove clamping 'instantly'
and allow all frequencies also the boost one. The highest possible
frequency is passed then to the this thermal pressure machinery.
So we see the warning that the boost frequency value is trying to
be passed to this arch_update_thermal_pressure(), but we ignore
such big frequency value and unfortunately do not clean the previously
set thermal pressure. Then the scheduler still sees the reduced
capacity on that CPU and cannot request higher frequencies.

The v4 patch would allow to pass the boost frequencies values, so
the issue would be solved.

Regards,
Lukasz

Sounds good, I look forward to testing v4 :)

-- steev




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux