From: Sudeep Holla <sudeep.holla@arm.com>
To: Michael Tretter <m.tretter@pengutronix.de>
Cc: Rajan Vaja <RAJANV@xilinx.com>,
Sudeep Holla <sudeep.holla@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Michal Simek <michals@xilinx.com>,
Jolly Shah <JOLLYS@xilinx.com>
Subject: Re: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE
Date: Tue, 20 Apr 2021 15:18:47 +0100 [thread overview]
Message-ID: <20210420141847.blcjrrvekjt6llck@bogus> (raw)
In-Reply-To: <20210419073239.GA12636@pengutronix.de>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-20 14:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 16:04 [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE Michael Tretter
2021-03-17 16:04 ` [PATCH 1/4] soc: xilinx: move PM_INIT_FINALIZE to zynqmp_pm_domains driver Michael Tretter
2021-03-17 16:04 ` [PATCH 2/4] soc: xilinx: cleanup debug and error messages Michael Tretter
2021-03-17 16:04 ` [PATCH 3/4] soc: xilinx: use a properly named field instead of flags Michael Tretter
2021-03-17 16:04 ` [PATCH 4/4] soc: xilinx: add a to_zynqmp_pm_domain macro Michael Tretter
2021-04-15 16:27 ` [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE Rajan Vaja
2021-04-19 7:32 ` Michael Tretter
2021-04-19 12:29 ` Rajan Vaja
2021-04-20 14:18 ` Sudeep Holla [this message]
2021-04-28 13:17 ` Michal Simek
2021-06-01 8:49 ` Michael Tretter
2021-06-01 9:17 ` Rajan Vaja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210420141847.blcjrrvekjt6llck@bogus \
--to=sudeep.holla@arm.com \
--cc=JOLLYS@xilinx.com \
--cc=RAJANV@xilinx.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=m.tretter@pengutronix.de \
--cc=michals@xilinx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).