On Tue, 2024-04-09 at 16:36 +0200, Lucas Stach wrote: > Am Dienstag, dem 09.04.2024 um 14:22 +0100 schrieb Vitor Soares: > > Hi Lucas, > > > > Thanks for your feedback. > > > > On Tue, 2024-04-09 at 11:13 +0200, Lucas Stach wrote: > > > Hi Vitor, > > > > > > Am Dienstag, dem 09.04.2024 um 09:58 +0100 schrieb Vitor Soares: > > > > From: Vitor Soares <vitor.soares@xxxxxxxxxxx> > > > > > > > > The pgc_vpu_* nodes miss the reference to the power domain > > > > parent, > > > > leading the system to hang during the resume. > > > > > > > This change is not correct. The vpumix domain is controlled > > > through > > > the > > > imx8mm-vpu-blk-ctrl and must not be directly triggered by the > > > child > > > domains in order to guarantee proper power sequencing. > > > > > > If the sequencing is incorrect for resume, it needs to be fixed > > > in > > > the > > > blk-ctrl driver. I'll happily assist if you have any questions > > > about > > > this intricate mix between GPC and blk-ctrl hardware/drivers. > > > > I'm new into the topic, so I tried to follow same approach as in > > imx8mp > > DT. > > > That's a good hint, the 8MP VPU GPC node additions missed my radar. > The > direct dependency there between the GPC domains is equally wrong. > > > I also checked the imx8mq DT and it only have one domain for the > > VPU in the GPC. It seem blk-ctrl also dependes on pgc_vpu_* to work > > properly. > > > > The blk-ctrl driver hangs on imx8m_blk_ctrl_power_on() when access > > the > > ip registers for the soft reset. I tried to power-up the before the > > soft reset, but it didn't work. > > > The runtime_pm_get_sync() at the start of that function should ensure > that bus GPC domain aka vpumix is powered up. Can you check if that > is > happening? I checked bc->bus_power_dev->power.runtime_status and it is RPM_ACTIVE. Am I looking to on the right thing? It is RPM_ACTIVE event before runtime_pm_get_sync(). > > Regards, > Lucas > > > Do you have an idea how we can address this within blk-ctrl? > > > > Best regards, > > Vitor
