All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Doug Anderson <dianders@chromium.org>
Cc: David Collins <collinsd@codeaurora.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-arm-msm@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Date: Wed, 23 May 2018 16:40:57 +0100	[thread overview]
Message-ID: <20180523154057.GL4828@sirena.org.uk> (raw)
In-Reply-To: <CAD=FV=XfPkpGD32MfTfcw02wQ+QetpUhY=P299uhpX6pY_iEvg@mail.gmail.com>

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

On Wed, May 23, 2018 at 08:23:22AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, May 23, 2018 at 1:29 AM, Mark Brown <broonie@kernel.org> wrote:
> 
> > It's arguable either way - you could say that the client gets to specify
> > a safe range at all times or you could say that the machine constraints
> > should cover all cases where the hardware is idling.  Of course RPMh
> > is missing anything like the machine constraints (as we can see from all
> > the fixing up of undesirable hard coding we have to do) so it's kind of
> > pushed towards the first case.

> OK, fair enough.  If others all agree that it's OK to make requests
> about the voltage of a disabled regulator then I won't stand in the
> way.  I guess it does call into question the whole idea of caching /
> not sending the voltage until the first enable because it means
> there's no way for the client to use this feature until they've
> enabled / disabled the regulator once.  If you think of it as invalid
> to adjust the voltage of a disabled regulator then the caching
> argument is super clean, but once you say that you should normally be

It's got to be valid to think about the voltage of a disabled regulator
since drivers want to be able make sure that the regulator gets enabled
with a sensible config.  With most hardware this is really easy since
you can just look at the status reported by the hardware but the RPM
makes this hard since there's so much write only stuff in there.

> able to do it it feels more like a hacky workaround.  ...but I suppose
> that's what we've got to live with...

These RPM systems are always going to have problems of some kind
unfortunately unless the interface changes.

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

WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
Date: Wed, 23 May 2018 16:40:57 +0100	[thread overview]
Message-ID: <20180523154057.GL4828@sirena.org.uk> (raw)
In-Reply-To: <CAD=FV=XfPkpGD32MfTfcw02wQ+QetpUhY=P299uhpX6pY_iEvg@mail.gmail.com>

On Wed, May 23, 2018 at 08:23:22AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Wed, May 23, 2018 at 1:29 AM, Mark Brown <broonie@kernel.org> wrote:
> 
> > It's arguable either way - you could say that the client gets to specify
> > a safe range at all times or you could say that the machine constraints
> > should cover all cases where the hardware is idling.  Of course RPMh
> > is missing anything like the machine constraints (as we can see from all
> > the fixing up of undesirable hard coding we have to do) so it's kind of
> > pushed towards the first case.

> OK, fair enough.  If others all agree that it's OK to make requests
> about the voltage of a disabled regulator then I won't stand in the
> way.  I guess it does call into question the whole idea of caching /
> not sending the voltage until the first enable because it means
> there's no way for the client to use this feature until they've
> enabled / disabled the regulator once.  If you think of it as invalid
> to adjust the voltage of a disabled regulator then the caching
> argument is super clean, but once you say that you should normally be

It's got to be valid to think about the voltage of a disabled regulator
since drivers want to be able make sure that the regulator gets enabled
with a sensible config.  With most hardware this is really easy since
you can just look at the status reported by the hardware but the RPM
makes this hard since there's so much write only stuff in there.

> able to do it it feels more like a hacky workaround.  ...but I suppose
> that's what we've got to live with...

These RPM systems are always going to have problems of some kind
unfortunately unless the interface changes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180523/9671d53b/attachment.sig>

  reply	other threads:[~2018-05-23 15:40 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-12  2:28 [PATCH v3 0/2] regulator: add QCOM RPMh regulator driver David Collins
2018-05-12  2:28 ` David Collins
2018-05-12  2:28 ` David Collins
2018-05-12  2:28 ` [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings David Collins
2018-05-12  2:28   ` David Collins
2018-05-17 21:22   ` Doug Anderson
2018-05-17 21:22     ` Doug Anderson
2018-05-18  0:16     ` David Collins
2018-05-18  0:16       ` David Collins
2018-05-18  1:01       ` Doug Anderson
2018-05-18  1:01         ` Doug Anderson
2018-05-19  0:46         ` David Collins
2018-05-19  0:46           ` David Collins
2018-05-21 18:01           ` Doug Anderson
2018-05-21 18:01             ` Doug Anderson
2018-05-22  0:00             ` David Collins
2018-05-22  0:00               ` David Collins
2018-05-22 16:43               ` Doug Anderson
2018-05-22 16:43                 ` Doug Anderson
2018-05-22 16:43                 ` Doug Anderson
2018-05-22 16:55                 ` Mark Brown
2018-05-22 16:55                   ` Mark Brown
2018-05-22 22:46                 ` David Collins
2018-05-22 22:46                   ` David Collins
2018-05-23  0:08                   ` Doug Anderson
2018-05-23  0:08                     ` Doug Anderson
2018-05-23  1:19                     ` David Collins
2018-05-23  1:19                       ` David Collins
2018-05-23  5:10                       ` Doug Anderson
2018-05-23  5:10                         ` Doug Anderson
2018-05-23  8:29                     ` Mark Brown
2018-05-23  8:29                       ` Mark Brown
2018-05-23 15:23                       ` Doug Anderson
2018-05-23 15:23                         ` Doug Anderson
2018-05-23 15:40                         ` Mark Brown [this message]
2018-05-23 15:40                           ` Mark Brown
2018-05-23 15:50                           ` Doug Anderson
2018-05-23 15:50                             ` Doug Anderson
2018-05-23 15:56                             ` Mark Brown
2018-05-23 15:56                               ` Mark Brown
2018-05-30  5:30                               ` Doug Anderson
2018-05-30  5:30                                 ` Doug Anderson
2018-05-30  9:37                                 ` Mark Brown
2018-05-30  9:37                                   ` Mark Brown
2018-05-30 14:46                                   ` Doug Anderson
2018-05-30 14:46                                     ` Doug Anderson
2018-05-30 15:02                                     ` Mark Brown
2018-05-30 15:02                                       ` Mark Brown
2018-05-30 15:34                                       ` Doug Anderson
2018-05-30 15:34                                         ` Doug Anderson
2018-05-30 15:48                                         ` Mark Brown
2018-05-30 15:48                                           ` Mark Brown
2018-05-30 16:06                                           ` Doug Anderson
2018-05-30 16:06                                             ` Doug Anderson
2018-05-30 16:07                                             ` Mark Brown
2018-05-30 16:07                                               ` Mark Brown
2018-05-30 16:09                                               ` Doug Anderson
2018-05-30 16:09                                                 ` Doug Anderson
2018-05-30 16:13                                                 ` Mark Brown
2018-05-30 16:13                                                   ` Mark Brown
2018-05-30 16:31                                                   ` Doug Anderson
2018-05-30 16:31                                                     ` Doug Anderson
2018-05-30 16:36                                                     ` Mark Brown
2018-05-30 16:36                                                       ` Mark Brown
2018-05-30 16:41                                                       ` Doug Anderson
2018-05-30 16:41                                                         ` Doug Anderson
2018-05-30 16:41                                                         ` Doug Anderson
2018-05-30 16:59                                                         ` Mark Brown
2018-05-30 16:59                                                           ` Mark Brown
2018-05-18 22:24       ` Rob Herring
2018-05-18 22:24         ` Rob Herring
2018-05-12  2:28 ` [PATCH v3 2/2] regulator: add QCOM RPMh regulator driver David Collins
2018-05-12  2:28   ` David Collins
2018-05-17 21:23   ` Doug Anderson
2018-05-17 21:23     ` Doug Anderson
2018-05-18  0:16     ` David Collins
2018-05-18  0:16       ` David Collins

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=20180523154057.GL4828@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=collinsd@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rnayak@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.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.