From: pawel.moll@arm.com (Pawel Moll)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 04/13] regulators: Versatile Express regulator driver
Date: Thu, 20 Sep 2012 18:34:32 +0100 [thread overview]
Message-ID: <1348162472.11116.149.camel@hornet> (raw)
In-Reply-To: <20120920130114.GQ17666@opensource.wolfsonmicro.com>
On Thu, 2012-09-20 at 14:01 +0100, Mark Brown wrote:
> > Actually before I finally got this mail (our mail system was playing
> > stupid today), I came up with idea of using the power supply specified
> > tolerance as a base to chose the step sizes. This comes down to such
> > code (with the regulator_*_voltage_linear in the ops):
>
> That's probably OK, though check that the numbers come out sensible
> (people tend to work to nice round numbers).
These calculations try to maximize the range, but in most cases it's
impossible to be exactly in line with constraints. The delta should be
less then 1%, eg. in my test case I get:
A15 Vcore: override max_uV, 1050000 -> 1049990
A15 Vcore: 800 <--> 1049 mV at 906 mV
I could try to add more math to interpolate the operating points to get
perfect match, but this sounds like a serious overkill...
> > + if (ret < 0) {
> > + /* No operating points defined, allow any value within range */
> > + struct regulation_constraints *constraints =
> > + regulator->rdev->constraints;
> > +
> > + return min_uV >= constraints->min_uV &&
> > + max_uV <= constraints->max_uV;
> > + }
>
> I'd rather have the driver explicitly say it supports continuous
> voltages with a flag in the descriptor (to make sure we don't end up
> being overly optimistic because the driver wasn't well implemented)
Ok, so I see two options:
1. Something like bool "regulator_desc.linear"
2. A magic value for regulator_desc.n_voltages, something like
#define N_VOLTAGES_LINEAR (~0)
Does any of them seem reasonable?
Pawel
next prev parent reply other threads:[~2012-09-20 17:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-18 14:17 [PATCH v2 00/13] Versatile Express infrastructure Pawel Moll
2012-09-18 14:17 ` [PATCH v2 01/13] input: ambakmi: (Un)prepare clocks when (dis)enabling Pawel Moll
2012-09-18 14:17 ` [PATCH v2 02/13] video: Versatile Express display output driver Pawel Moll
2012-09-18 14:17 ` [PATCH v2 03/13] hwmon: Versatile Express hwmon driver Pawel Moll
2012-09-18 15:24 ` Guenter Roeck
2012-09-18 15:45 ` Jean Delvare
2012-09-18 20:59 ` Guenter Roeck
2012-09-19 17:04 ` Pawel Moll
2012-09-20 2:03 ` Guenter Roeck
2012-09-18 14:17 ` [PATCH v2 04/13] regulators: Versatile Express regulator driver Pawel Moll
2012-09-18 15:02 ` Mark Brown
2012-09-18 15:44 ` Pawel Moll
2012-09-18 16:09 ` Mark Brown
2012-09-18 17:03 ` Pawel Moll
2012-09-19 2:21 ` Mark Brown
2012-09-19 16:58 ` Pawel Moll
2012-09-20 13:01 ` Mark Brown
2012-09-20 17:34 ` Pawel Moll [this message]
2012-09-20 18:15 ` Mark Brown
2012-09-18 14:17 ` [PATCH v2 05/13] clk: Versatile Express clock generators ("osc") driver Pawel Moll
2012-10-29 17:44 ` Mike Turquette
2012-09-18 14:17 ` [PATCH v2 06/13] clk: Common clocks implementation for Versatile Express Pawel Moll
2012-09-18 14:17 ` [PATCH v2 07/13] misc: Versatile Express config infrastructure Pawel Moll
2012-09-19 13:08 ` Arnd Bergmann
2012-09-20 12:06 ` Pawel Moll
2012-09-20 12:36 ` Arnd Bergmann
2012-09-20 12:37 ` Pawel Moll
2012-09-18 14:17 ` [PATCH v2 08/13] mfd: Versatile Express system registers driver Pawel Moll
2012-09-18 15:24 ` Arnd Bergmann
2012-09-19 10:53 ` Pawel Moll
2012-09-19 11:17 ` Arnd Bergmann
2012-09-19 11:45 ` Pawel Moll
2012-09-18 14:17 ` [PATCH v2 09/13] ARM: vexpress: Reset driver Pawel Moll
2012-09-18 14:17 ` [PATCH v2 10/13] ARM: vexpress: Add config bus components and clocks to DTs Pawel Moll
2012-09-18 14:17 ` [PATCH v2 11/13] ARM: vexpress: Start using new Versatile Express infrastructure Pawel Moll
2012-09-18 14:17 ` [PATCH v2 12/13] ARM: vexpress: Remove motherboard dependencies in the DTS files Pawel Moll
2012-09-18 14:17 ` [PATCH v2 13/13] ARM: vexpress: Make the DEBUG_LL UART detection more specific Pawel Moll
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=1348162472.11116.149.camel@hornet \
--to=pawel.moll@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).