All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter De Schrijver <pdeschrijver@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-tegra@vger.kernel.org, linux-clk@vger.kernel.org,
	mturquette@baylibre.com, sboyd@codeaurora.org,
	robh+dt@kernel.org, mark.rutland@arm.com,
	devicetree@vger.kernel.org, lgirdwood@gmail.com,
	linux-kernel@vger.kernel.org,
	Laxman Dewangan <ldewangan@nvidia.com>
Subject: Re: [PATCH v3 01/11] regulator: core: add API to get voltage constraints
Date: Wed, 7 Feb 2018 17:20:45 +0200	[thread overview]
Message-ID: <20180207152045.GC5850@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <20180207150155.GD6003@sirena.org.uk>

On Wed, Feb 07, 2018 at 03:01:55PM +0000, Mark Brown wrote:
> On Wed, Feb 07, 2018 at 04:32:13PM +0200, Peter De Schrijver wrote:
> > On Wed, Feb 07, 2018 at 02:18:46PM +0000, Mark Brown wrote:
> 
> > > You're going to have to provide a much better explanation of what this
> > > is doing - right now it seems like an abuse of constraints.  Client
> > > drivers can already determine if a particular voltage they want to set
> > > is available via regulator_list_voltage() and so on, that's what
> > > constraints are there to set.  It sounds like you're trying to use them
> > > for something else but you're really not explaining your use case
> > > clearly.
> 
> > There is no way to query what voltage I will actually get for a given input
> 
> I looked at patch 2.  It looked like an abuse of what constraints do,
> and had zero explanation of why it was doing what it was doing.  In any
> case we need the regulator code and changelog to be clear about what the
> interface is for and why it should be used, that's not happening here.
> 
> > voltage. If you read drivers/clk/tegra/cvb. (you did do that right?), you
> > will see that there is a minimum and maximum voltage defined by
> > charaterization which needs to be capped to the regulator generated voltages
> > for those points.
> 
> I can't really tell what you're saying here.  If the driver needs to
> know if it can set the a given voltage there's already an API for doing
> that as I said.  If you're trying to convey this minimum and maximum
> voltage via the constraints that sounds like an abuse of the constraints.


No, what I want is the voltage which the regulator will output for a given
regulator_set_voltage request taking constraints, regulator step etc into
account.

Peter.

WARNING: multiple messages have this Message-ID (diff)
From: Peter De Schrijver <pdeschrijver@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: <linux-tegra@vger.kernel.org>, <linux-clk@vger.kernel.org>,
	<mturquette@baylibre.com>, <sboyd@codeaurora.org>,
	<robh+dt@kernel.org>, <mark.rutland@arm.com>,
	<devicetree@vger.kernel.org>, <lgirdwood@gmail.com>,
	<linux-kernel@vger.kernel.org>,
	Laxman Dewangan <ldewangan@nvidia.com>
Subject: Re: [PATCH v3 01/11] regulator: core: add API to get voltage constraints
Date: Wed, 7 Feb 2018 17:20:45 +0200	[thread overview]
Message-ID: <20180207152045.GC5850@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <20180207150155.GD6003@sirena.org.uk>

On Wed, Feb 07, 2018 at 03:01:55PM +0000, Mark Brown wrote:
> On Wed, Feb 07, 2018 at 04:32:13PM +0200, Peter De Schrijver wrote:
> > On Wed, Feb 07, 2018 at 02:18:46PM +0000, Mark Brown wrote:
> 
> > > You're going to have to provide a much better explanation of what this
> > > is doing - right now it seems like an abuse of constraints.  Client
> > > drivers can already determine if a particular voltage they want to set
> > > is available via regulator_list_voltage() and so on, that's what
> > > constraints are there to set.  It sounds like you're trying to use them
> > > for something else but you're really not explaining your use case
> > > clearly.
> 
> > There is no way to query what voltage I will actually get for a given input
> 
> I looked at patch 2.  It looked like an abuse of what constraints do,
> and had zero explanation of why it was doing what it was doing.  In any
> case we need the regulator code and changelog to be clear about what the
> interface is for and why it should be used, that's not happening here.
> 
> > voltage. If you read drivers/clk/tegra/cvb. (you did do that right?), you
> > will see that there is a minimum and maximum voltage defined by
> > charaterization which needs to be capped to the regulator generated voltages
> > for those points.
> 
> I can't really tell what you're saying here.  If the driver needs to
> know if it can set the a given voltage there's already an API for doing
> that as I said.  If you're trying to convey this minimum and maximum
> voltage via the constraints that sounds like an abuse of the constraints.


No, what I want is the voltage which the regulator will output for a given
regulator_set_voltage request taking constraints, regulator step etc into
account.

Peter.

  reply	other threads:[~2018-02-07 15:20 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-06 16:34 [PATCH v3 00/11] Tegra210 DFLL implementation Peter De Schrijver
2018-02-06 16:34 ` Peter De Schrijver
     [not found] ` <1517934852-23255-1-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-02-06 16:34   ` [PATCH v3 01/11] regulator: core: add API to get voltage constraints Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-02-06 16:35     ` Mark Brown
     [not found]       ` <20180206163544.GI5681-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2018-02-07  8:47         ` Peter De Schrijver
2018-02-07  8:47           ` Peter De Schrijver
2018-02-07 10:43           ` Mark Brown
     [not found]             ` <20180207104351.GA6003-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2018-02-07 12:37               ` Peter De Schrijver
2018-02-07 12:37                 ` Peter De Schrijver
     [not found]                 ` <20180207123750.GA5850-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2018-02-07 14:18                   ` Mark Brown
2018-02-07 14:18                     ` Mark Brown
2018-02-07 14:32                     ` Peter De Schrijver
2018-02-07 14:32                       ` Peter De Schrijver
     [not found]                       ` <20180207143213.GB5850-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2018-02-07 15:01                         ` Mark Brown
2018-02-07 15:01                           ` Mark Brown
2018-02-07 15:20                           ` Peter De Schrijver [this message]
2018-02-07 15:20                             ` Peter De Schrijver
     [not found]                             ` <20180207152045.GC5850-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2018-02-07 15:37                               ` Mark Brown
2018-02-07 15:37                                 ` Mark Brown
     [not found]                                 ` <20180207153711.GE6003-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2018-02-08 10:04                                   ` Laxman Dewangan
2018-02-08 10:04                                     ` Laxman Dewangan
     [not found]                                     ` <86cd40ac-d255-f4b9-87cb-0cd34efba7d8-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-02-08 14:58                                       ` Mark Brown
2018-02-08 14:58                                         ` Mark Brown
2018-02-06 16:34   ` [PATCH v3 02/11] clk: tegra: retrieve regulator info from framework Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:26     ` Jon Hunter
2018-03-08 22:26       ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 03/11] clk: tegra: dfll registration for multiple SoCs Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:15     ` Jon Hunter
2018-03-08 22:15       ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 04/11] clk: tegra: add CVB tables for Tegra210 CPU DFLL Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:28     ` Jon Hunter
2018-03-08 22:28       ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 05/11] clk: tegra: prepare dfll driver for PWM regulator Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:50     ` Jon Hunter
2018-03-08 22:50       ` Jon Hunter
2018-03-12  9:14       ` Peter De Schrijver
2018-03-12  9:14         ` Peter De Schrijver
2018-03-12 11:08         ` Jon Hunter
2018-03-12 11:08           ` Jon Hunter
2018-03-13  9:03           ` Peter De Schrijver
2018-03-13  9:03             ` Peter De Schrijver
2018-03-13 10:07             ` Jon Hunter
2018-03-13 10:07               ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 07/11] dt-bindings: tegra: Update DFLL binding " Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
     [not found]     ` <1517934852-23255-8-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-02-09 23:19       ` Rob Herring
2018-02-09 23:19         ` Rob Herring
2018-03-08 23:21     ` Jon Hunter
2018-03-08 23:21       ` Jon Hunter
2018-03-12  9:10       ` Peter De Schrijver
2018-03-12  9:10         ` Peter De Schrijver
2018-02-06 16:34   ` [PATCH v3 09/11] cpufreq: tegra124-cpufreq: extend to support Tegra210 Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 23:25     ` Jon Hunter
2018-03-08 23:25       ` Jon Hunter
2018-03-09  8:14       ` Peter De Schrijver
2018-03-09  8:14         ` Peter De Schrijver
2018-03-12 10:14         ` Jon Hunter
2018-03-12 10:14           ` Jon Hunter
2018-03-13  9:28           ` Peter De Schrijver
2018-03-13  9:28             ` Peter De Schrijver
2018-03-09  9:11     ` Viresh Kumar
2018-03-12 12:15     ` Jon Hunter
2018-03-12 12:15       ` Jon Hunter
2018-03-13  9:51       ` Peter De Schrijver
2018-03-13  9:51         ` Peter De Schrijver
2018-03-13 10:20         ` Jon Hunter
2018-03-13 10:20           ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 10/11] arm64: dts: tegra: Add Tegra210 DFLL definition Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-02-06 16:34   ` [PATCH v3 11/11] arm64: dts: nvidia: Tegra210 CPU clock definition Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-02-06 16:34 ` [PATCH v3 06/11] clk: tegra: dfll: support PWM regulator control Peter De Schrijver
2018-02-06 16:34   ` Peter De Schrijver
2018-03-08 23:15   ` Jon Hunter
2018-03-08 23:15     ` Jon Hunter
2018-03-09  8:12     ` Peter De Schrijver
2018-03-09  8:12       ` Peter De Schrijver
2018-02-06 16:34 ` [PATCH v3 08/11] clk: tegra: build clk-dfll.c for Tegra124 and Tegra210 Peter De Schrijver
2018-02-06 16:34   ` Peter De Schrijver
2018-03-08 23:22   ` Jon Hunter
2018-03-08 23:22     ` Jon Hunter

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=20180207152045.GC5850@tbergstrom-lnx.Nvidia.com \
    --to=pdeschrijver@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ldewangan@nvidia.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.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.