[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210617162919.GH5067@sirena.org.uk>
Date: Thu, 17 Jun 2021 17:29:19 +0100
From: Mark Brown <broonie@...nel.org>
To: ChiYuan Huang <u0084500@...il.com>
Cc: Rob Herring <robh@...nel.org>, lgirdwood@...il.com,
matthias.bgg@...il.com, gene_chen@...htek.com,
lkml <linux-kernel@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, cy_huang <cy_huang@...htek.com>,
gene.chen.richtek@...il.com
Subject: Re: [PATCH 1/2] regulator: mt6360: Add optional
mediatek.power-off-sequence in bindings document
On Mon, Jun 14, 2021 at 11:04:01PM +0800, ChiYuan Huang wrote:
> Rob Herring <robh@...nel.org> 於 2021年6月12日 週六 上午4:16寫道:
> > > Originally, we think it must write in platform dependent code like as bootloader.
> > > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > > For the other cases, just follow HW immediate off by default.
> > Wouldn't this be handled by PSCI implementation?
> No, the current application default on powers buck1/buck2/ldo7/ldo6
> are for Dram power.
> It's not the soc core power. It seems not appropriate to implement
> like as PSCI.
> MT6360 play the role for the subpmic in the SOC application reference design.
If this is part of the overall system power off that seems like it fits
well enough into what PSCI is doing - it's got operations like
SYSTEM_OFF which talk about the system as a whole.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists