On Mon, 16 Nov 2020 at 17:17, Jon Hunter <jonathanh@xxxxxxxxxx> wrote: > > Hi all, > > We recently ran into a problem on Tegra186 where it was failing to > resume from suspend. It turned out that a driver, the Tegra ACONNECT > (drivers/bus/tegra-aconnect.c), was being resumed before the PM domain > provider, the BPMP (drivers/firmware/tegra/bpmp.c), and the Tegra > ACONNECT was trying to enable the PM domain before the provider had been > resumed. > > According to commit 4d23a5e84806 it states that 'genpd powers on the PM > domain unconditionally in the system PM resume "noirq" phase'. However, > what I don't see is anything that guarantees that the provider is > resumed before any device that requires power domains. Unless there is > something that I am missing? The genpd provider's ->power_on() callback should be invoked as soon as an attached device gets resumed via the ->resume_noirq() callback (genpd_resume_noirq). Have you verified that this is working as expected for you? Note that, if there is no device attached to the genpd, the ->power_on() callback may not be invoked - unless there is a child domain being powered on. >From the genpd provider driver point of view - why do you need to implement system suspend/resume callbacks at all? Do you have some additional operations to run, besides those executed from the ->power_on|off() callbacks? > > Now by default the ACONNECT is resumed during the noirq phase, but I > have tried making it and its child devices, suspend/resume in the normal > system phase but this does not seem to make a difference. So I am > looking for a bit of guidance on how best to fix this. The order of suspend/resume of devices are based upon the order the devices get stored in the "dpm list" - unless there are child/parents relationships or device-links that the PM core also takes into account. Kind regards Uffe
