kernel/linux.git/drivers/opp/opp.h, branch v6.12.80

OPP: Rename 'rate_clk_single'

2024-01-05T10:25:41+00:00

The field's name isn't clear enough. Rename it. Signed-off-by: Viresh Kumar

OPP: Move dev_pm_opp_icc_bw to internal opp.h

2024-01-03T10:51:42+00:00

It isn't used by any driver or API, privatize it. Signed-off-by: Viresh Kumar

OPP: Call dev_pm_opp_set_opp() for required OPPs

2023-11-28T10:33:19+00:00

Configuring the required OPP was never properly implemented, we just took an exception for genpds and configured them directly, while leaving out all other required OPP types. Now that a standard call to dev_pm_opp_set_opp() takes care of configuring the opp->level too, the special handling for genpds can be avoided by simply calling dev_pm_opp_set_opp() for the required OPPs, which shall eventually configure the corresponding level for genpds. This also makes it possible for us to configure other type of required OPPs (no concrete users yet though), via the same path. This is how other frameworks take care of parent nodes, like clock, regulators, etc, where we recursively call the same helper. In order to call dev_pm_opp_set_opp() for the virtual genpd devices, they must share the OPP table of the genpd. Call _add_opp_dev() for them to get that done. This commit also extends the struct dev_pm_opp_config to pass required devices, for non-genpd cases, which can be used to call dev_pm_opp_set_opp() for the non-genpd required devices. Reviewed-by: Ulf Hansson Tested-by: Stephan Gerhold Signed-off-by: Viresh Kumar

OPP: Remove genpd_virt_dev_lock

2023-10-17T05:41:28+00:00

All the config operations for OPP tables share common code paths now and none of the other ones have such protection in place. Either all should have it or none. The understanding here is that user won't clear the OPP configs while still using them and so such a case won't happen. We can always come back and use a wider lock for all resource types if required. Also fix the error on failing to allocate memory. Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson

OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility

2023-10-06T07:07:33+00:00

The dev_pm_opp_add() API is limited to add dynamic OPPs with a frequency and a voltage level. To enable more flexibility, let's add a new API, dev_pm_opp_add_dynamic() that's takes a struct dev_pm_opp_data* instead of a list of in-parameters. Signed-off-by: Ulf Hansson Signed-off-by: Viresh Kumar

OPP: Simplify the over-designed pstate <-> level dance

2023-06-19T04:20:09+00:00

While adding support for "performance states" in the OPP and genpd core, it was decided to set the `pstate` field via genpd's pm_genpd_opp_to_performance_state() helper, to allow platforms to set `pstate` even if they don't have a corresponding `level` field in the DT OPP tables (More details are present in commit 6e41766a6a50 ("PM / Domain: Implement of_genpd_opp_to_performance_state()")). Revisiting that five years later clearly suggests that it was over-designed as all current users are eventually using the `level` value only. The previous commit already added necessary checks to make sure pstate is only used for genpd tables. Lets now simplify this a little, and use `level` directly and remove `pstate` field altogether. Suggested-by: Ulf Hansson Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson

OPP: don't drop performance constraint on OPP table removal

2023-06-14T09:24:01+00:00

This code was added (long back) by commit 009acd196fc8 ("PM / OPP: Support updating performance state of device's power domain") and at that time the `opp->pstate` field was used to store the performance state required by a device's OPP. Over time that changed and the `->pstate` field is now used only for genpd devices and consumer devices access that via the required-opps instead. Because of all these changes, _opp_table_kref_release() now drops the constraint only when the genpd's OPP table gets freed and not the device's. Which is definitely not what we wanted. And dropping the constraint doesn't have much meaning as the genpd itself is going away. Moreover, if we want to drop constraints here, then just dropping the performance constraint alone isn't sufficient as there are other resource constraints like clk, regulator, etc. too, which must be handled. Probably the right thing to do here is to leave this decision to the consumers, which can call `dev_pm_opp_set_rate(dev, 0)` or similar APIs to drop all constraints properly. Which many of the consumers already do. Remove the special code, which is broken anyway. Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson

OPP: Staticize `lazy_opp_tables` in of.c

2023-06-08T07:25:07+00:00

`lazy_opp_tables` is only used in of.c, move it there and mark it `static`. Signed-off-by: Viresh Kumar

OPP: Move required opps configuration to specialized callback

2023-04-03T04:15:09+00:00

The required-opps configuration is closely tied to genpd and performance states at the moment and it is not very obvious that required-opps can live without genpds. Though we don't support configuring required-opps for non-genpd cases currently. This commit aims at separating these parts, where configuring genpds would be a special case of configuring the required-opps. Add a specialized callback, set_required_opps(), to the opp table and set it to different callbacks accordingly. This shouldn't result in any functional changes for now. Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson

OPP: Don't drop opp->np reference while it is still in use

2022-07-19T05:37:02+00:00

The struct dev_pm_opp contains a reference of the DT node, opp->np, throughout its lifetime. We should increase the refcount for the same from _opp_add_static_v2(), and drop it while removing the OPP finally. Signed-off-by: Liang He [ Viresh: Updated subject / commit log, create _of_clear_opp() and drop reference from it] Signed-off-by: Viresh Kumar