kernel.git/drivers/base/power/domain.c, branch linux-5.19.y

PM: domains: Ensure genpd_debugfs_dir exists before remove

2022-08-17T13:14:17Z

[ Upstream commit 37101d3c719386040ded735a5ec06974f1d94d1f ] Both genpd_debug_add() and genpd_debug_remove() may be called indirectly by other drivers while genpd_debugfs_dir is not yet set. For example, drivers can call pm_genpd_init() in probe or pm_genpd_init() in probe fail/cleanup path: pm_genpd_init() --> genpd_debug_add() pm_genpd_remove() --> genpd_remove() --> genpd_debug_remove() At this time, genpd_debug_init() may not yet be called. genpd_debug_add() checks that if genpd_debugfs_dir is NULL, it will return directly. Make sure this is also checked in pm_genpd_remove(), otherwise components under debugfs root which has the same name as other components under pm_genpd may be accidentally removed, since NULL represents debugfs root. Fixes: 718072ceb211 ("PM: domains: create debugfs nodes when adding power domains") Signed-off-by: Hsin-Yi Wang Reviewed-by: Greg Kroah-Hartman Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

PM: domains: Trust domain-idle-states from DT to be correct by genpd

2022-05-19T18:16:05Z

If genpd has parsed the domain-idle-states from DT, it's reasonable to believe that the parsed data should be correct for the HW in question. Based upon this, it seem superfluous to let genpd measure the corresponding power-on/off latencies for these states. Therefore, let's improve the behaviour in genpd by avoiding the measurements for the domain-idle-states that have been parsed from DT. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Measure power-on/off latencies in genpd based on a governor

2022-05-19T18:16:05Z

The measurements of the power-on|off latencies in genpd for a PM domain are superfluous, unless the corresponding genpd has a governor assigned to it, which would make use of the data. Therefore, let's improve the behaviour in genpd by making the measurements conditional, based upon if there's a governor assigned. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Allocate governor data dynamically based on a genpd governor

2022-05-19T18:16:05Z

If a genpd doesn't have an associated governor assigned, several variables in the struct generic_pm_domain becomes superfluous. Rather than wasting memory in allocated genpds, let's move the variables from the struct generic_pm_domain into a new separate struct. In this way, we can instead dynamically decide when we need to allocate the corresponding data for it. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Clean up some code in pm_genpd_init() and genpd_remove()

2022-05-19T18:16:05Z

To improve the readability of the code, let's move the parts that deals with allocation/freeing of data, into two separate functions. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Fix initialization of genpd's next_wakeup

2022-05-19T18:16:05Z

In the genpd governor we walk the list of child-domains to take into account their next_wakeup. If the child-domain itself, doesn't have a governor assigned to it, we can end up using the next_wakeup value before it has been properly initialized. To prevent a possible incorrect behaviour in the governor, let's initialize next_wakeup to KTIME_MAX. Fixes: c79aa080fb0f ("PM: domains: use device's next wakeup to determine domain idle state") Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Fixup QoS latency measurements for IRQ safe devices in genpd

2022-05-19T18:16:05Z

When an IRQ safe device is attached to a non-IRQ safe PM domain, genpd needs to prevent the PM domain from being powered off. However, genpd still allows the device to be runtime suspended/resumed, hence it's also reasonable to think that a governor may be used to validate the QoS latency constraints. Unfortunately, genpd_runtime_resume() treats the configuration above, as a reason to skip measuring the QoS resume latency for the device. This is a legacy behaviour that was earlier correct, but should have been changed when genpd was transformed into its current behaviour around how it manages IRQ safe devices. Luckily, there's no report about problems, so let's just fixup the behaviour. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Measure suspend/resume latencies in genpd based on governor

2022-05-19T18:16:05Z

The QoS latency measurements for devices in genpd_runtime_suspend|resume() are superfluous, unless the corresponding genpd has a governor assigned to it, which would make use of the data. Therefore, let's improve the behaviour in genpd by making the measurements conditional, based upon if there's a governor assigned. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Move the next_wakeup variable into the struct gpd_timing_data

2022-05-19T18:16:05Z

If the corresponding genpd for the device doesn't use a governor, the variable next_wakeup within the struct generic_pm_domain_data becomes superfluous. To avoid wasting memory, let's move it into the struct gpd_timing_data, which is already being allocated based upon if there is governor assigned. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM: domains: Allocate gpd_timing_data dynamically based on governor

2022-05-19T18:16:05Z

If a genpd doesn't have an associated governor assigned, there's really no point to allocate the per device gpd_timing_data, as the data isn't being used by a governor anyway. To avoid wasting memory, let's therefore convert the corresponding td variable in the struct generic_pm_domain_data into a pointer and manage the allocation of its data dynamically. Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki