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]
Message-ID: <20161213231452.GB96889@google.com>
Date:   Tue, 13 Dec 2016 15:14:52 -0800
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Brian Norris <briannorris@...omium.org>,
        Javier Martinez Canillas <javier@...hile0.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v4 4/4] regulator: Prevent falling too fast

Hi,

El Tue, Dec 13, 2016 at 12:00:32PM -0800 Doug Anderson ha dit:

> On Tue, Dec 13, 2016 at 9:19 AM, Mark Brown <broonie@...nel.org> wrote:
> > On Mon, Dec 12, 2016 at 01:15:02PM -0800, Matthias Kaehlcke wrote:
> >> El Fri, Oct 28, 2016 at 07:15:21PM +0100 Mark Brown ha dit:
> >> > On Mon, Sep 26, 2016 at 10:41:59AM -0700, Doug Anderson wrote:
> >
> >> > What you're describing to me is a discrete DCDC that has an input
> >> > voltage that sets the output voltage which happens to be set with a PWM.
> >
> >> I experimented a bit with this. Besides the question of how to model
> >> the passives I wonder how the two regulators would interact. The
> >> correct thing seems to be to specify the input regulator as a supply
> >> of the DCDC. dcdc->set_voltage breaks down a voltage transition into
> >
> > No, not unless the prior descriptions of the hardware have been wildly
> > inaccurate - my understanding had been that the DCDC was a normal DCDC
> > with an analogue input intended to be biased to set the output voltage
> > (presumably in terms of a full rail supply) and that the PWM had been
> > connected to this analogue input.  If the PWM is supplying the DCDC then
> > the hardware design just seems bizzare, I can't see how this would even
> > work.
> 
> Looking at one schematic, the discrete BUCK for at least one of the
> rails is TPS65261RHBR, which appears to be described at
> <https://store.ti.com/TPS65261RHBR.aspx>.  Data sheet appears to be at
> <http://www.ti.com/product/tps65261/technicaldocuments?HQS=TI-null-null-octopart-df-pf-null-wwe>.
> 
> As you can see from the datasheet ("Adjusting the Output Voltage"
> section), it is intended that you stuff a resistor to make a voltage
> divider and that's how you select the output voltage.  In our case the
> PWM interacts here and allows you to make a more dynamic output
> voltage.  I've always thought about the input to the "FB" pin as
> making an input voltage, but I guess it's not terribly simple since
> the voltage divider ends up dividing between ground and the output
> voltage.

I also had put my mind on seeing the output of the PWM circuitry as an
input voltage, but technically it isn't a supply of the buck
regulator. It seems we could consider it a "control voltage" instead
and thus avoid the recursive lock acquisition.

Matthias

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ