Re: [PATCH 0/7] Minor cleanup for thermal gov power allocator

From: Lukasz Luba
Date: Fri Nov 24 2023 - 02:45:03 EST




On 11/23/23 19:50, Rafael J. Wysocki wrote:
Hi Lukasz,

On Thu, Nov 23, 2023 at 4:19 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:

Hi Rafael,

Gentle ping

On 10/26/23 13:22, Lukasz Luba wrote:


On 10/26/23 09:54, Rafael J. Wysocki wrote:
On Wed, Oct 25, 2023 at 9:21 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:

Hi all,

The patch set does some small clean up for Intelligent Power Allocator.
Those changes are not expected to alter the general functionality.
They just
improve the code reading. Only patch 3/7 might improve the use case for
binding the governor to thermal zone (very unlikely in real products,
but
it's needed for correctness).

The changes are based on top of current PM thermal branch, so with the
new trip points.

Regards,
Lukasz

Lukasz Luba (7):
thermal: gov_power_allocator: Rename trip_max_desired_temperature
thermal: gov_power_allocator: Setup trip points earlier
thermal: gov_power_allocator: Check the cooling devices only for
trip_max
thermal: gov_power_allocator: Rearrange the order of variables
thermal: gov_power_allocator: Use shorter variable when possible
thermal: gov_power_allocator: Remove unneeded local variables
thermal: gov_power_allocator: Clean needed variables at the beginning

drivers/thermal/gov_power_allocator.c | 123 ++++++++++++++------------
1 file changed, 64 insertions(+), 59 deletions(-)

--

The series looks good to me overall, but I'd prefer to make these
changes in the 6.8 cycle, because the 6.7 merge window is around the
corner and there is quite a bit of thermal material in this cycle
already.

Thanks for having a look! Yes, I agree, we can wait after the
merge window. It just have to be cleaned one day a bit and I postponed
this a few times, so no rush ;)

I've seen you've created the new pm/thermal. Could you consider to take
those in, please?

Sure, I'll get to them presumably tomorrow and if not then early next week.

OK, thank you Rafael!


I would send some RFC on top showing the issue with reading back the CPU
max frequency from the PM_QoS chain.

Sounds good.