[PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE

[Michal Simek]

Hi,

On 4/20/21 4:18 PM, Sudeep Holla wrote:
> 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.

Rajan: Can you please do deep dive to this in pmufw and try to figured
it out how to fix this on firmware side?

Thanks,
Michal