linux-kernel - Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 14 Jun 2021 23:04:01 +0800
From:   ChiYuan Huang <u0084500@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     lgirdwood@...il.com, Mark Brown <broonie@...nel.org>,
        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

Hi, Rob:

Rob Herring <robh@...nel.org> 於 2021年6月12日 週六 上午4:16寫道：
>
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@...htek.com>
> >
> > Add optional mediatek.power-off-sequence in bindings document.
> >
> > Signed-off-by: ChiYuan Huang <cy_huang@...htek.com>
> > ---
> > Hi,
> >
> > 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.
>
> > ---
> >  .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > index a462d99..eaf36e2 100644
> > --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > @@ -24,6 +24,16 @@ properties:
> >    LDO_VIN3-supply:
> >      description: Input supply phandle(s) for LDO6/7
> >
> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4
>
> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc?
No. you may misunderstand. there's an external 'Enable' pin that's
connected to the main pmic.
The starting point of delay time are all from  the external 'Enable' H to L.
Not one-by-one delay time,
> If we wanted to express this in DT, we'd made this generic which would
> need to be more flexible. A poweroff delay in each regulator (similar to
> the existing power on delay) would be sufficient for what you need I
> think.
Power on sequence already defined by the part number, It's not decided by SW.
So for the flexibility, I implement it in DT.

Duel to there're many part number MT6360 P/UP/LP, etc.
The difference are the power on sequence.

Do you have any suggestion about this situation?

PS: Due to DRAM power usage , sometimes it also need to customized by
the DRAM that customer choosed.
It may differ from external DRAM part choosen following by JEDEC spec.
>
> Rob