All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Mark Brown <broonie@sirena.org.uk>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
	lkml <linux-kernel@vger.kernel.org>,
	OMAP <linux-omap@vger.kernel.org>
Subject: Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
Date: Mon, 23 Feb 2009 18:22:27 -0800	[thread overview]
Message-ID: <200902231822.27422.david-b@pacbell.net> (raw)
In-Reply-To: <20090224005536.GC3601@sirena.org.uk>

On Monday 23 February 2009, Mark Brown wrote:
> > > Yeah, I kind of agree.  To avoid confusion from changing the names I'd
> > > be tempted to go for something like "regulator driver constraints" but
> > > it's not desparately nice.
> 
> > Hence my suggestion:  {regulator,machine,consumer} constraints,
> > going from bottom up.  They aren't driver constraints; they
> > are hardware constraints:  regulators can't supply arbitrary
> > voltages.
> 
> Trouble is that the term regulator gets very overloaded and causes
> confusion.

That's why one of the *first* jobs in architecture is to
ensure the terminology doesn't easily overload ... there's
always trouble when it isn't.  Despite early groans from
peanut galleries about "language lawyering" and "wanting
to code in C not English", etc.  ;)

Thing is, there's already overloading here.  Two types
of regulator -- "struct regulator_dev" wrapping hardware,
and the "struct regulator" is a client/consumer handle.
(And thus confusing to me, since it sounds like the more
fundamental concept, but instead it's a few layers up.)

If you're concerned about overloading terminology, then
best to address it sooner than later.  I've noticed you
using the "consumer", "machine", and "regulator" terms
more or less like I suggested, and those make sense; but
the current struct names don't encourage that usage.  It's
possible to adjust usage before changing names in "C".
Thankfully, in Linux global name struct changes are not
rejected out of hand.


> There's also fun and games to be had with accuracy once you 
> start looking too closely at the discrete voltages.

Yes; the patch I sent is explicitly making those available.

But I ignored issues like "+/- 3% accurate output" for LDOs
(or switchers) ... if anyone really needs to address them,
patches will be needed.  For now I only care that a 3.1 Volt
output can match both MMC_VDD_30_31 and MMC_VDD_31_32! ;)

- Dave




WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Mark Brown <broonie@sirena.org.uk>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
	lkml <linux-kernel@vger.kernel.org>,
	OMAP <linux-omap@vger.kernel.org>
Subject: Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
Date: Mon, 23 Feb 2009 18:22:27 -0800	[thread overview]
Message-ID: <200902231822.27422.david-b@pacbell.net> (raw)
In-Reply-To: <20090224005536.GC3601@sirena.org.uk>

On Monday 23 February 2009, Mark Brown wrote:
> > > Yeah, I kind of agree.  To avoid confusion from changing the names I'd
> > > be tempted to go for something like "regulator driver constraints" but
> > > it's not desparately nice.
> 
> > Hence my suggestion:  {regulator,machine,consumer} constraints,
> > going from bottom up.  They aren't driver constraints; they
> > are hardware constraints:  regulators can't supply arbitrary
> > voltages.
> 
> Trouble is that the term regulator gets very overloaded and causes
> confusion.

That's why one of the *first* jobs in architecture is to
ensure the terminology doesn't easily overload ... there's
always trouble when it isn't.  Despite early groans from
peanut galleries about "language lawyering" and "wanting
to code in C not English", etc.  ;)

Thing is, there's already overloading here.  Two types
of regulator -- "struct regulator_dev" wrapping hardware,
and the "struct regulator" is a client/consumer handle.
(And thus confusing to me, since it sounds like the more
fundamental concept, but instead it's a few layers up.)

If you're concerned about overloading terminology, then
best to address it sooner than later.  I've noticed you
using the "consumer", "machine", and "regulator" terms
more or less like I suggested, and those make sense; but
the current struct names don't encourage that usage.  It's
possible to adjust usage before changing names in "C".
Thankfully, in Linux global name struct changes are not
rejected out of hand.


> There's also fun and games to be had with accuracy once you 
> start looking too closely at the discrete voltages.

Yes; the patch I sent is explicitly making those available.

But I ignored issues like "+/- 3% accurate output" for LDOs
(or switchers) ... if anyone really needs to address them,
patches will be needed.  For now I only care that a 3.1 Volt
output can match both MMC_VDD_30_31 and MMC_VDD_31_32! ;)

- Dave



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-02-24  2:24 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-08 18:37 [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators David Brownell
2009-02-08 23:29 ` Mark Brown
2009-02-09  0:04   ` David Brownell
2009-02-09  0:04     ` David Brownell
2009-02-09 17:27     ` Mark Brown
2009-02-10  0:24       ` David Brownell
2009-02-10 22:48         ` Mark Brown
2009-02-23 20:45           ` David Brownell
2009-02-23 20:52             ` [patch/rfc 2.6.29-rc6 1/2] regulator: enumerate voltages David Brownell
2009-02-24 22:23               ` Mark Brown
2009-02-25  0:17                 ` David Brownell
2009-02-25 15:17                   ` Mark Brown
2009-02-25 22:12                     ` David Brownell
2009-02-25 23:01                       ` Mark Brown
2009-02-25 23:47                         ` David Brownell
2009-02-25 23:47                           ` David Brownell
2009-02-26 11:05                           ` Mark Brown
2009-02-26  1:02                     ` David Brownell
2009-02-26  1:02                       ` David Brownell
2009-02-26 10:46                       ` Mark Brown
2009-02-26 18:56                         ` David Brownell
2009-02-26 19:05                           ` Mark Brown
2009-02-26 19:38                             ` David Brownell
2009-02-26 20:02                               ` Liam Girdwood
2009-02-26 20:59                                 ` David Brownell
2009-02-26 20:59                                   ` David Brownell
2009-02-26 19:48               ` [patch 2.6.29-rc6 1/2] regulator: enumerate voltages (v2) David Brownell
2009-02-26 20:20                 ` Mark Brown
2009-02-26 21:12                   ` David Brownell
2009-02-26 21:48                     ` [patch 2.6.29-rc6+misc] MMC: regulator utilities David Brownell
2009-03-02 20:59                       ` Pierre Ossman
2009-03-02 21:27                         ` David Brownell
2009-03-02 21:40                           ` Pierre Ossman
2009-03-02 22:00                             ` David Brownell
2009-03-04  3:18                               ` David Brownell
2009-03-08 13:59                                 ` Pierre Ossman
2009-03-08 20:34                                   ` David Brownell
2009-03-08 21:49                                     ` Pierre Ossman
2009-03-09 11:52                                       ` Liam Girdwood
2009-03-11 11:30                                         ` David Brownell
2009-03-11 14:34                                           ` Liam Girdwood
2009-02-26 20:53                 ` [patch 2.6.29-rc6 1/2] regulator: enumerate voltages (v2) Liam Girdwood
2009-02-26 21:28                   ` David Brownell
2009-02-26 21:58                     ` Liam Girdwood
2009-02-27  0:10                       ` David Brownell
2009-02-23 20:54             ` [patch/rfc 2.6.29-rc6 2/2] regulator: twl4030 voltage enumeration David Brownell
2009-02-26 19:50               ` [patch/rfc 2.6.29-rc6 2/2] regulator: twl4030 voltage enumeration (v2) David Brownell
2009-02-26 20:25                 ` Mark Brown
2009-02-26 22:16                 ` Liam Girdwood
2009-02-27  0:02                   ` David Brownell
2009-02-27  0:02                     ` David Brownell
2009-02-27 12:32                     ` Liam Girdwood
2009-02-27 20:39                       ` David Brownell
2009-02-27 21:26                         ` Liam Girdwood
2009-03-03 22:59                       ` David Brownell
2009-03-04 11:47                         ` Liam Girdwood
2009-02-23 22:04             ` [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators Mark Brown
2009-02-23 22:43               ` David Brownell
2009-02-24  0:55                 ` Mark Brown
2009-02-24  2:03                   ` David Brownell
2009-02-24 12:41                     ` Mark Brown
2009-02-24  2:22                   ` David Brownell [this message]
2009-02-24  2:22                     ` David Brownell
2009-02-24  7:25                     ` David Brownell
2009-02-24  7:25                       ` David Brownell
2009-02-26 22:15 ` Liam Girdwood

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=200902231822.27422.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=broonie@sirena.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    /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.