[PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE
Sudeep Holla
sudeep.holla at arm.com
Tue Apr 20 15:18:47 BST 2021
On Mon, Apr 19, 2021 at 09:32:39AM +0200, Michael Tretter wrote:
Sorry for chiming in randomly. I always though the way PM_INIT_FINALIZE
is designed has issues(e.g. racy). I was involved in discussion with
Xilinx when we will designing more generic version of EEMI - SCMI
which is now supported in upstream. EEMI was in production already when
we started on SCMI 3-4 years back and wanted to get feedback.
[...]
>
> What is the reason why all devices have to be requested before calling
> zynqmp_pm_init_finalize()?
>
Yes that is wrong assumption/expectation from the firmware.
> I was expecting that calling PM_INIT_FINALIZE only would tell the PMU_FW that
> Linux is using the PM API and the PMU_FW should power down/up PM slaves as
> requested by Linux. It is somewhat surprising that this isn't the case and all
> PM slaves have to be powered up before calling PM_INIT_FINALIZE.
>
Agreed that was my understanding too.
> What would happen if some driver is built as a module? In that case, the
> module would be loaded and request the pm node only after PM_INIT_FINALIZE was
> called. Do we have to avoid/disallow such cases?
>
I was told it will work. But it will be always racy if there are multiple
channels to talk to firmware.
My argument firmware can turn off all the devices before giving control
to OS and no need for that. But there is some boot time optimisation
possible I am told which I could well be. But this interface for too
racy IMO, just happens to be fine with limited configurations it operates
in.
--
Regards,
Sudeep
More information about the linux-arm-kernel
mailing list