linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
	Michael Tretter <m.tretter@pengutronix.de>
Cc: Rajan Vaja <RAJANV@xilinx.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE
Date: Wed, 28 Apr 2021 15:17:25 +0200	[thread overview]
Message-ID: <93cdc435-448f-233b-5b3f-b4ff1d47f897@xilinx.com> (raw)
In-Reply-To: <20210420141847.blcjrrvekjt6llck@bogus>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-28 13:19 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
2021-04-28 13:17       ` Michal Simek [this message]
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=93cdc435-448f-233b-5b3f-b4ff1d47f897@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=RAJANV@xilinx.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=m.tretter@pengutronix.de \
    --cc=sudeep.holla@arm.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).