[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADiBU39-HA518TP=7_i8bYQWfhAUK_pj+Gn0O6rTKEZxq6GR1A@mail.gmail.com>
Date: Fri, 18 Jun 2021 11:28:41 +0800
From: ChiYuan Huang <u0084500@...il.com>
To: Mark Brown <broonie@...nel.org>
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
Mark Brown <broonie@...nel.org> 於 2021年6月18日 週五 上午12:29寫道:
>
> 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.
Thanks, I'll check and survey the PSCI about the SYSTEM_OFF.
I think it may work.
Powered by blists - more mailing lists