All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Sakoman <sakoman@gmail.com>
To: Mark Brown <broonie@sirena.org.uk>
Cc: Grazvydas Ignotas <notasas@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	David Brownell <david-b@pacbell.net>
Subject: Re: Overo broken with current top of tree
Date: Thu, 30 Apr 2009 08:07:16 -0700	[thread overview]
Message-ID: <5e088bd90904300807r2ddecfb3vd3f16ae8d2bfb4ce@mail.gmail.com> (raw)
In-Reply-To: <20090430101619.GE10190@sirena.org.uk>

On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown <broonie@sirena.org.uk> wrote:
> On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
>> On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>
>> > set_machine_constraints: invalid 'VUSB1V5' voltage constraints
>
>> I get the same on pandora, although it continues booting fine after
>> that. Maybe regulator folks will comment about regulator errors.
>
> I suspect this may be due to the buggy defaults that are provided when
> no voltage constraints are given for a fixed voltage regulator.  There's
> a patch on its way to mainline fixing this:

Thanks Mark!  This patch does indeed fix the regulator issues, and the
system seems to operate normally once again.

The platform data messages still appear, but a quick look at the code
that generates them shows that we are at the start of a transition in
how platform data is handled (both old and new style are handled at
the moment).  Seems we will have a bit of work to do to adapt.

i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030_gpio: use which platform_data?
twl4030: gpio (irq 368) chaining IRQs 384..401
mmci-omap-hs.0: use which platform_data?
mmci-omap-hs.1: use which platform_data?
twl4030_usb: use which platform_data?
twl4030_reg.6: use which platform_data?
regulator: VMMC1: 1850 <--> 3150 mV normal standby
twl4030_reg.17: use which platform_data?
regulator: VUSB1V5: 1500 mV normal standby
twl4030_reg.18: use which platform_data?
regulator: VUSB1V8: 1800 mV normal standby
twl4030_reg.19: use which platform_data?
regulator: VUSB3V1: 3100 mV normal standby


Steve


>
> commit 14d32bb077f7cc6f78bd012e5b1489899dddf749
> Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Date:   Tue Apr 28 11:09:38 2009 +0100
>
>    regulator: Fix default constraints for fixed voltage regulators
>
>    Default voltage constraints were being provided for fixed voltage
>    regulator where board constraints were not provided but these constraints
>    used INT_MIN as the default minimum voltage which is not a valid value
>    since it is less than zero. Use 1uV instead.
>
>    Also set the default values we set in the constraints themselves since
>    otherwise the max_uV constraint we determine will not be stored in the
>    actual constraint strucutre and will therefore not be used.
>
>    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
>    Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 2f14c16..98c3a74 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -703,10 +703,13 @@ static int set_machine_constraints(struct regulator_dev *rdev,
>                int     cmin = constraints->min_uV;
>                int     cmax = constraints->max_uV;
>
> -               /* it's safe to autoconfigure fixed-voltage supplies */
> +               /* it's safe to autoconfigure fixed-voltage supplies
> +                  and the constraints are used by list_voltage. */
>                if (count == 1 && !cmin) {
> -                       cmin = INT_MIN;
> +                       cmin = 1;
>                        cmax = INT_MAX;
> +                       constraints->min_uV = cmin;
> +                       constraints->max_uV = cmax;
>                }
>
>                /* voltage constraints are optional */
>
--
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

  reply	other threads:[~2009-04-30 15:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29 16:03 Overo broken with current top of tree Steve Sakoman
2009-04-30  9:31 ` Grazvydas Ignotas
2009-04-30 10:16   ` Mark Brown
2009-04-30 15:07     ` Steve Sakoman [this message]
2009-04-30 15:24       ` Tony Lindgren
2009-04-30 15:53         ` Premi, Sanjeev
2009-04-30 17:41       ` David Brownell
2009-04-30 17:50         ` Steve Sakoman
2009-04-30 18:07           ` David Brownell
2009-04-30 10:23   ` David Brownell

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=5e088bd90904300807r2ddecfb3vd3f16ae8d2bfb4ce@mail.gmail.com \
    --to=sakoman@gmail.com \
    --cc=broonie@sirena.org.uk \
    --cc=david-b@pacbell.net \
    --cc=linux-omap@vger.kernel.org \
    --cc=notasas@gmail.com \
    /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.