linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: eric.y.miao@gmail.com (Eric Miao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/10] mmp: append device support in jasper
Date: Thu, 29 Apr 2010 12:01:04 +0800	[thread overview]
Message-ID: <h2nf17812d71004282101nf780329cq5ba0f50aa48dab5b@mail.gmail.com> (raw)
In-Reply-To: <n2h771cded01004282005j709b34dfq50c591bf8dc0defa@mail.gmail.com>

On Thu, Apr 29, 2010 at 11:05 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Wed, Apr 28, 2010 at 9:52 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
>> On Wed, Apr 28, 2010 at 08:23:24AM -0400, Haojian Zhuang wrote:
>>
>>> +static struct regulator_consumer_supply regulator_supply[] = {
>>
>> You shouldn't have all your consumer supplies in one big array, each
>> regulator should have its own set of supplies for the devices connected
>> to it.
>>
>>> + ? ? [MAX8925_ID_SD1] ? ? ? ?= REGULATOR_SUPPLY("v_sd1", NULL),
>>> + ? ? [MAX8925_ID_SD2] ? ? ? ?= REGULATOR_SUPPLY("v_sd2", NULL),
>>> + ? ? [MAX8925_ID_SD3] ? ? ? ?= REGULATOR_SUPPLY("v_sd3", NULL),
>>> + ? ? [MAX8925_ID_LDO1] ? ? ? = REGULATOR_SUPPLY("v_ldo1", NULL),
>>> + ? ? [MAX8925_ID_LDO2] ? ? ? = REGULATOR_SUPPLY("v_ldo2", NULL),
>>
>> None of these supplies should be being defined at all - the supplies
>> from regulators are for hooking up individual device supplies to the
>> regulators, you should only have supplies with null devices in
>> exceptional cases like CPUfreq where no usable struct device exists.
>>
>> I'm fairly sure this has been pointed out with regard to previous
>> machines you have submitted regulator support for, it is disappointing
>> to see the same issue coming up again.
>>
>>> +#define REG_INIT(_name, _min, _max, _always, _boot) ? ? ? ? ?\
>>> +{ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? .constraints = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? ? ? ? ? .name ? ? ? ? ? = __stringify(_name), ? ? ? ? ? \
>>> + ? ? ? ? ? ? .min_uV ? ? ? ? = _min, ? ? ? ? ? ? ? ? ? ? ? ? \
>>> + ? ? ? ? ? ? .max_uV ? ? ? ? = _max, ? ? ? ? ? ? ? ? ? ? ? ? \
>>> + ? ? ? ? ? ? .always_on ? ? ?= _always, ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? ? ? ? ? .boot_on ? ? ? ?= _boot, ? ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? ? ? ? ? .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE, ? ? \
>>> + ? ? }, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? .num_consumer_supplies ?= 1, ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>>> + ? ? .consumer_supplies ? ? ?= &regulator_supply[MAX8925_ID_##_name], \
>>
>> This macro shouldn't be assuming that there are devices being supplied,
>> and definitely needs to be able to cope with more than one regulator
>> using the supply.
>>
>>> +static struct regulator_init_data regulator_data[] = {
>>> + ? ? [MAX8925_ID_SD1] = REG_INIT(SD1, 637500, 1425000, 0, 0),
>>> + ? ? [MAX8925_ID_SD2] = REG_INIT(SD2, 650000, 2225000, 1, 1),
>>> + ? ? [MAX8925_ID_SD3] = REG_INIT(SD3, 750000, 3900000, 1, 1),
>>> + ? ? [MAX8925_ID_LDO1] = REG_INIT(LDO1, 750000, 3900000, 1, 1),
>>> + ? ? [MAX8925_ID_LDO2] = REG_INIT(LDO2, 650000, 2250000, 1, 1),
>>
>> Have all the voltage ranges you're specifying here been audited against
>> the board design? ?It would be very unusual for every single supply on
>> the board have such wide voltage ranges - it looks awfully like the
>> ranges here are the supported ranges for the regulators themselves.
>>
>
> OK. Update this patch by removing regulators in max8925. They'll be
> contained in later patches. Whatever I think a big array is suitable
> for unused regulators. Is it right?
>

Mark,

I need your Ack on this. Thanks.

  reply	other threads:[~2010-04-29  4:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-28 12:23 [PATCH 10/10] mmp: append device support in jasper Haojian Zhuang
2010-04-28 13:11 ` Eric Miao
2010-04-28 13:41   ` Haojian Zhuang
2010-04-28 13:52 ` Mark Brown
2010-04-29  3:05   ` Haojian Zhuang
2010-04-29  4:01     ` Eric Miao [this message]
2010-04-29  9:17     ` 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=h2nf17812d71004282101nf780329cq5ba0f50aa48dab5b@mail.gmail.com \
    --to=eric.y.miao@gmail.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).