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
next prev 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: linkBe 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.