From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Ashish Jangam <Ashish.Jangam@kpitcummins.com>
Cc: "lrg@slimlogic.co.uk" <lrg@slimlogic.co.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Dajun Chen <Dajun.Chen@diasemi.com>
Subject: Re: [PATCHv1 5/11] REGULATOR: Regulator module of DA9052 PMIC driver
Date: Fri, 15 Apr 2011 11:36:07 +0100 [thread overview]
Message-ID: <20110415103555.GF23466@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <E2CAE7F7B064EA49B5CE7EE9A4BB167D151B619753@KCINPUNHJCMS01.kpit.com>
On Wed, Apr 13, 2011 at 05:42:08PM +0530, Ashish Jangam wrote:
> Changes made since last submission:
> . Change the regulator registration method
> . Ported the driver to Linux kernel 2.6.38.2
> Linux Kernel Version: 2.6.38.2
As I've repeatedly told you you should submit patches against -next.
Please stop doing this, it's getting repetitive. A few comments from a
breif scan through:
> +static struct regulator_consumer_supply da9052_vddarm_consumers[] = {
> + {
> + .supply = "vcc",
> + }
> +};
Supplies are connected to regulators using the machine driver not
drivers for specific regulators.
> + if (offset == DA9052_BUCK_PERI) {
> + if (regval >= DA9052_BUCK_PERI_REG_MAP_UPTO_3uV) {
> + regval_uV = ((DA9052_BUCK_PERI_REG_MAP_UPTO_3uV *
> + da9052_regulator_info[offset].step_uV)
> + + constraints->min_uV);
> + regval_uV += (regval -
> + DA9052_BUCK_PERI_REG_MAP_UPTO_3uV)
> + *(DA9052_BUCK_PERI_3uV_STEP);
> + } else {
> + regval_uV =
> + (regval * da9052_regulator_info[offset].step_uV)
> + + constraints->min_uV;
> + }
Given this and the number of other differences it seems like you should
just define separate ops for BUCK_PERI.
> +static int da9052_regulator_set_voltage(struct regulator_dev *rdev, int min_uV,
> + int max_uV, unsigned *selector)
> +{
> + struct da9052 *da9052 = to_da9052(rdev);
> + int offset = rdev_get_id(rdev);
> + int ret;
> + int reg_val = 0;
> +
> + reg_val = da9052_regulator_uvolts_to_regVal(rdev, min_uV);
You're completely ignoring the max_uV constraint here.
> +static int da9052_list_voltage(struct regulator_dev *rdev, unsigned selector)
> +{
> + struct regulation_constraints *constraints = rdev->constraints;
> + struct da9052_regulator_info *info = rdev_get_drvdata(rdev);
> + int ret;
> +
> + ret = constraints->min_uV + info->step_uV * selector;
> + if (ret > constraints->max_uV)
> + return -EINVAL;
This looks *very* broken. Why are you looking at the constraints to
determine what the selector means?
next prev parent reply other threads:[~2011-04-15 10:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-13 12:12 [PATCHv1 5/11] REGULATOR: Regulator module of DA9052 PMIC driver Ashish Jangam
2011-04-15 9:15 ` Liam Girdwood
2011-04-15 10:36 ` Mark Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-04-06 12:49 Ashish Jangam
2011-04-06 14:05 ` Mark Brown
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=20110415103555.GF23466@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=Ashish.Jangam@kpitcummins.com \
--cc=Dajun.Chen@diasemi.com \
--cc=linux-kernel@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 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).