On 23. 8. 2022, at 13:31, Mark Brown broonie@kernel.org wrote:
On Tue, Aug 23, 2022 at 09:33:36AM +0200, Martin Povišer wrote:
On 22. 8. 2022, at 19:39, Mark Brown broonie@kernel.org wrote: On Fri, Aug 19, 2022 at 02:54:29PM +0200, Martin Povišer wrote:
- /*
* We can't power up the device earlier than this because
* the power state driver would error out on seeing the device
* as clock-gated.
*/
- cl->pd_link = device_link_add(mca->dev, cl->pd_dev,
DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME |
DL_FLAG_RPM_ACTIVE);
I'm not clear on this dynamically adding and removing device links stuff
- it looks like the main (only?) purpose is to take a runtime PM
reference to the target device which is fine but it's not clear why device links are involved given that the links are created and destroyed every time the DAI is used, AFAICT always in the same fixed relationship. It's not a problem, it's just unclear.
Indeed the only purpose is powering up the cluster’s power domain (there’s one domain for each cluster). Adding the links is the only way I know to do it. They need to be added dynamically (as opposed to statically linking, say, the DAI’s ->dev to the cluster’s ->pd_dev, which I guess may do something similar), because we need to sequence the power-up/power-down with the enablement of the clocks.
You could also just do the underlying runtime power management operations directly couldn't you? It's not clear what the device link stuff is adding.
This seems to be the way to do it. Quoting from documentation of dev_pm_domain_attach_by_id, by which we obtain the mca->dev and cl->pd_dev the link is between:
* This function should typically be invoked by a driver during the probe phase, * in case its device requires power management through multiple PM domains. The * driver may benefit from using the received device, to configure device-links * towards its original device. Depending on the use-case and if needed, the * links may be dynamically changed by the driver, which allows it to control * the power to the PM domains independently from each other.
-- Martin