Linux-Samsung-soc Archive on lore.kernel.org
 help / color / Atom feed
WARNING: multiple messages have this Message-ID
From: Mark Brown <broonie@kernel.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	linux-samsung-soc@vger.kernel.org,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Kamil Konieczny <k.konieczny@samsung.com>
Subject: Re: [PATCH] regulator: core: Skip balancing of the enabled regulators in regulator_enable()
Date: Tue, 8 Oct 2019 17:15:35 +0100
Message-ID: <20191008161535.GN4382@sirena.co.uk> (raw)
In-Reply-To: <be8d3280-9855-ed18-b2ab-d7fb28d80b82@gmail.com>


[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Tue, Oct 08, 2019 at 06:02:36PM +0300, Dmitry Osipenko wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> That OPP patch caused the same problem for the NVIDIA Tegra20 CPUFreq
> driver (in-progress) and I resolved it in the coupler's code [0].
> Perhaps the generic coupler could do the same thing by assuming that
> min_uV=current_uV until any consumer sets the voltage, i.e. if
> regulator_check_consumers(min_uV=0) returns min_uV=0.

That sounds like it might just postpone the inevitable - if you set the
wrong voltage first it might decide to drop down some voltage that
wasn't expected.  There's a bit of a bootstrapping issue.  I think it
would be safer to just say that anything that is within spec won't get
changed any time we balance, we'd only change things if needed to bring
them back into spec.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

From: Mark Brown <broonie@kernel.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	linux-samsung-soc@vger.kernel.org,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Kamil Konieczny <k.konieczny@samsung.com>
Subject: Re: [PATCH] regulator: core: Skip balancing of the enabled regulators in regulator_enable()
Date: Tue, 8 Oct 2019 17:15:35 +0100
Message-ID: <20191008161535.GN4382@sirena.co.uk> (raw)
Message-ID: <20191008161535.VNGWMh6xlsy9pB7YQ3akC1bTB-9V_0jA_o6nzt4VTDI@z> (raw)
In-Reply-To: <be8d3280-9855-ed18-b2ab-d7fb28d80b82@gmail.com>


[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Tue, Oct 08, 2019 at 06:02:36PM +0300, Dmitry Osipenko wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> That OPP patch caused the same problem for the NVIDIA Tegra20 CPUFreq
> driver (in-progress) and I resolved it in the coupler's code [0].
> Perhaps the generic coupler could do the same thing by assuming that
> min_uV=current_uV until any consumer sets the voltage, i.e. if
> regulator_check_consumers(min_uV=0) returns min_uV=0.

That sounds like it might just postpone the inevitable - if you set the
wrong voltage first it might decide to drop down some voltage that
wasn't expected.  There's a bit of a bootstrapping issue.  I think it
would be safer to just say that anything that is within spec won't get
changed any time we balance, we'd only change things if needed to bring
them back into spec.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply index

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20191008101720eucas1p2e0d1bca6e696848bf689067e05620679@eucas1p2.samsung.com>
2019-10-08 10:17 ` Marek Szyprowski
2019-10-08 10:17   ` Marek Szyprowski
2019-10-08 11:50   ` Mark Brown
2019-10-08 11:50     ` Mark Brown
2019-10-08 12:01     ` Marek Szyprowski
2019-10-08 12:01       ` Marek Szyprowski
2019-10-08 12:06       ` Mark Brown
2019-10-08 12:06         ` Mark Brown
2019-10-08 12:38         ` Marek Szyprowski
2019-10-08 12:38           ` Marek Szyprowski
2019-10-08 12:47           ` Mark Brown
2019-10-08 12:47             ` Mark Brown
2019-10-08 13:24             ` Bartlomiej Zolnierkiewicz
2019-10-08 13:24               ` Bartlomiej Zolnierkiewicz
2019-10-08 15:02               ` Dmitry Osipenko
2019-10-08 15:02                 ` Dmitry Osipenko
2019-10-08 16:15                 ` Mark Brown [this message]
2019-10-08 16:15                   ` Mark Brown
2019-10-08 17:05                   ` Dmitry Osipenko
2019-10-08 17:05                     ` Dmitry Osipenko
2019-10-08 17:17                     ` Mark Brown
2019-10-08 17:17                       ` Mark Brown
2019-10-08 18:00                       ` Dmitry Osipenko
2019-10-08 18:00                         ` Dmitry Osipenko
2019-10-08 18:07                         ` Mark Brown
2019-10-08 18:07                           ` Mark Brown
2019-10-09 10:29                           ` Marek Szyprowski
2019-10-09 10:29                             ` Marek Szyprowski
2019-10-09 14:13                             ` Mark Brown
2019-10-09 14:13                               ` Mark Brown
2019-10-10  7:29                               ` Viresh Kumar
2019-10-10  7:29                                 ` Viresh Kumar
2019-10-10 10:19                               ` Marek Szyprowski
2019-10-10 10:19                                 ` Marek Szyprowski
2019-10-10 13:55                                 ` Mark Brown
2019-10-10 13:55                                   ` Mark Brown
2019-10-17 10:29                                   ` Marek Szyprowski
2019-10-08 15:48               ` Mark Brown
2019-10-08 15:48                 ` Mark Brown
2019-10-08 16:02                 ` Bartlomiej Zolnierkiewicz
2019-10-08 16:02                   ` Bartlomiej Zolnierkiewicz
2019-10-08 16:21                   ` Mark Brown
2019-10-08 16: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=20191008161535.GN4382@sirena.co.uk \
    --to=broonie@kernel.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=digetx@gmail.com \
    --cc=k.konieczny@samsung.com \
    --cc=krzk@kernel.org \
    --cc=l.stach@pengutronix.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=viresh.kumar@linaro.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

Linux-Samsung-soc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-samsung-soc/0 linux-samsung-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-samsung-soc linux-samsung-soc/ https://lore.kernel.org/linux-samsung-soc \
		linux-samsung-soc@vger.kernel.org
	public-inbox-index linux-samsung-soc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-samsung-soc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git