Messages in this thread | | | Date | Mon, 3 Jul 2023 17:22:48 +0100 | Subject | Re: [PATCH v2 03/17] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible | From | Lukasz Luba <> |
| |
On 5/30/23 12:06, Dietmar Eggemann wrote: > On 12/05/2023 11:57, Lukasz Luba wrote: >> Prepare em_pd_get_efficient_state() for the upcoming changes and >> make it possible to re-use. Return an index for the best performance > > Don't get the `possible to re-use`? Did you mean `possible to be > re-used`? But then `re-used` for what?
The function will no longer get a pointer to 'struct em_perf_domain' but instead to 'struct em_perf_state'. It would also require to get the number of states from 'pd->nr_perf_states'.
This is preparation for handling 2 tables: modifiable (a) and default (b).
Then it also returns and ID not the pointer to state. It all makes it more generic and ready for those 2 tables.
> >> state. The function arguments that are introduced should allow to >> work on different performance state arrays. The caller of >> em_pd_get_efficient_state() should be able to use the index either >> on the default or the modifiable EM table. > > This describes the WHAT but not the WHY.
I will add that description as 'why' in the header. I wanted to avoid mentioning in the patch description something which is coming in the next patch.
| |