[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGb2v66GQUzp1oz-J_Boea_S_mWAkBaiZ=A5uSqEb3pNNvaCzA@mail.gmail.com>
Date: Wed, 6 Mar 2019 11:47:47 +0800
From: Chen-Yu Tsai <wens@...e.org>
To: Torsten Duwe <duwe@....de>
Cc: Carlo Caione <carlo@...one.org>,
Olliver Schinagl <oliver@...inagl.nl>,
Lee Jones <lee.jones@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Jagan Teki <jagan@...rulasolutions.com>,
Icenowy Zheng <icenowy@...c.io>,
devicetree <devicetree@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: device tree binding for poly-phased regulators
On Fri, Feb 22, 2019 at 7:21 PM Torsten Duwe <duwe@....de> wrote:
>
> Hi!
>
> Documentation/devicetree/bindings/mfd/axp20x.txt nicely describes the
> capabilities of the X-powers PMICs; however, it seems polyphasing is
> left to comments only.
>
> May I suggest to add a property "poly-phased", just to get the discussion
> started? It could be a simple property in the current case for the axp803
> and axp806 ("poly-phased with you-know-which") or a phandle in the future.
These PMICs are customized in a way that the outputs are poly-phased by
default. They are customized to match a specific SoC, and that is about
the only use for them. As such, there's really no way to test whether a
poly-phase property and implementation works or not. If you get it wrong
you risk frying your device.
A poly-phase property in genernal would be nice, however I don't think
this is the right device to start with.
> BTW the axp803 datasheet is quite terse in that respect: is there one
> "master" reulator whose settings are copied or does a driver have to keep
> them in sync.
The datasheet says, when outputs are poly-phased, only the settings of the
first phase applies, i.e. the other settings are ignored, not even copied.
ChenYu
Powered by blists - more mailing lists