From: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Brian Norris
<briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Javier Martinez Canillas
<javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v4 4/4] regulator: Prevent falling too fast
Date: Mon, 12 Dec 2016 13:15:02 -0800 [thread overview]
Message-ID: <20161212211502.GA96889@google.com> (raw)
In-Reply-To: <20161028181521.ywzmow6bgndfotq3-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
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:
>
> > I guess I think of the whole network of components as the PWM
> > regulator and not the individual discreet BUCK. I'm also not quite
> > sure how you would model it as you're asking. I suppose you could say
> > that all of the resistors / capacitors / inductors end up producing a
> > voltage and this voltage is an input to the BUCK. ...then the BUCK
>
> Yes, that's what's happening.
>
> > I know for sure that our EEs have massively modified the behavior of
> > the whole thing by just changing the resistors / capacitors /
> > inductors, changing the undershoot, OVP issue, voltage ranges, default
> > voltage, etc. That's what leads me to believe it's not so separable.
>
> 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.
> It's of course going to be the case that the passives are important to
> the system performance but it seems we have two bits here - the PWM
> regulator providing an input to the DCDC and the DCDC itself which is
> sensitive to rate changes.
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
steps (if needed) and calls regulator_set_voltage(supply) for each
step. The problem with that is that regulator_set_voltage(dcdc)
acquires the supply lock(s), later regulator_set_voltage(supply) tries
to acquire its own lock which is already held. This can be worked
around by only using the supply regulator in the DCDC, but not
specify it as a supply. However this seems more a hack than a proper
solution.
Am I missing something obvious here or approaching this from a wrong
angle?
Thanks
Matthias
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Kaehlcke <mka@chromium.org>
To: Mark Brown <broonie@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Brian Norris <briannorris@chromium.org>,
Javier Martinez Canillas <javier@dowhile0.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v4 4/4] regulator: Prevent falling too fast
Date: Mon, 12 Dec 2016 13:15:02 -0800 [thread overview]
Message-ID: <20161212211502.GA96889@google.com> (raw)
In-Reply-To: <20161028181521.ywzmow6bgndfotq3@sirena.org.uk>
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:
>
> > I guess I think of the whole network of components as the PWM
> > regulator and not the individual discreet BUCK. I'm also not quite
> > sure how you would model it as you're asking. I suppose you could say
> > that all of the resistors / capacitors / inductors end up producing a
> > voltage and this voltage is an input to the BUCK. ...then the BUCK
>
> Yes, that's what's happening.
>
> > I know for sure that our EEs have massively modified the behavior of
> > the whole thing by just changing the resistors / capacitors /
> > inductors, changing the undershoot, OVP issue, voltage ranges, default
> > voltage, etc. That's what leads me to believe it's not so separable.
>
> 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.
> It's of course going to be the case that the passives are important to
> the system performance but it seems we have two bits here - the PWM
> regulator providing an input to the DCDC and the DCDC itself which is
> sensitive to rate changes.
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
steps (if needed) and calls regulator_set_voltage(supply) for each
step. The problem with that is that regulator_set_voltage(dcdc)
acquires the supply lock(s), later regulator_set_voltage(supply) tries
to acquire its own lock which is already held. This can be worked
around by only using the supply regulator in the DCDC, but not
specify it as a supply. However this seems more a hack than a proper
solution.
Am I missing something obvious here or approaching this from a wrong
angle?
Thanks
Matthias
next prev parent reply other threads:[~2016-12-12 21:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 19:05 [PATCH v4 4/4] regulator: Prevent falling too fast Matthias Kaehlcke
2016-09-06 19:05 ` Matthias Kaehlcke
[not found] ` <20160906190524.GB79728-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2016-09-12 18:56 ` Mark Brown
2016-09-12 18:56 ` Mark Brown
[not found] ` <20160912185633.GH27946-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-09-13 17:21 ` Matthias Kaehlcke
2016-09-13 17:21 ` Matthias Kaehlcke
[not found] ` <20160913172140.GC62872-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2016-09-15 14:39 ` Mark Brown
2016-09-15 14:39 ` Mark Brown
[not found] ` <20160915143945.GJ27974-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-09-15 18:02 ` Matthias Kaehlcke
2016-09-15 18:02 ` Matthias Kaehlcke
[not found] ` <20160915180223.GE62872-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2016-09-16 16:32 ` Mark Brown
2016-09-16 16:32 ` Mark Brown
[not found] ` <20160916163253.GA10189-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-09-16 18:31 ` Matthias Kaehlcke
2016-09-16 18:31 ` Matthias Kaehlcke
[not found] ` <20160916183145.GF62872-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2016-09-16 18:48 ` Mark Brown
2016-09-16 18:48 ` Mark Brown
2016-09-19 18:39 ` Doug Anderson
2016-09-24 18:41 ` Mark Brown
[not found] ` <20160924184133.seh6v6eayt7hwgue-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-09-26 17:41 ` Doug Anderson
2016-09-26 17:41 ` Doug Anderson
2016-10-28 18:15 ` Mark Brown
[not found] ` <20161028181521.ywzmow6bgndfotq3-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-12-12 21:15 ` Matthias Kaehlcke [this message]
2016-12-12 21:15 ` Matthias Kaehlcke
[not found] ` <20161212211502.GA96889-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2016-12-13 17:19 ` Mark Brown
2016-12-13 17:19 ` Mark Brown
2016-12-13 20:00 ` Doug Anderson
2016-12-13 23:14 ` Matthias Kaehlcke
[not found] ` <CAD=FV=WhUVeq5GZ5-ae4SxypHGB9jWqgvkO02S=G6Zz6cexRzQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-14 13:21 ` Mark Brown
2016-12-14 13:21 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161212211502.GA96889@google.com \
--to=mka-f7+t8e8rja9g9huczpvpmw@public.gmane.org \
--cc=briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org \
--cc=lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.