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

[Rajan Vaja]

Hi Michael,

> -----Original Message-----
> From: Michael Tretter <m.tretter at pengutronix.de>
> Sent: 01 June 2021 02:19 PM
> To: Rajan Vaja <RAJANV at xilinx.com>; Michal Simek <michals at xilinx.com>
> Cc: Sudeep Holla <sudeep.holla at arm.com>; linux-arm-kernel at lists.infradead.org;
> kernel at pengutronix.de
> Subject: Re: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
> PM_INIT_FINALIZE
> 
> Hi Rajan,
> 
> On Wed, 28 Apr 2021 15:17:25 +0200, Michal Simek wrote:
> > 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.
> 
> Is it possible to use SCMI on the ZynqMP? I guess no, as I couldn't find any
> code that would make this possible. Correct?
[Rajan] Yes.

> 
> > >
> > > [...]
> > >
> > >>
> > >> 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?
> 
> Did you have time to look into this?
> 
> There are 3 more cleanup patches in this series. Are there any objections
> against these patches? I think the other patches are still useful by
> themselves.
[Rajan] I am okay with this however, pm_init_finalize() needs to be late call. 
It can be taken later as it is not late call right now in mainline. 

> 
> Michael