> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Tony Lindgren > Sent: Thursday, April 30, 2009 8:55 PM > To: Steve Sakoman > Cc: Mark Brown; Grazvydas Ignotas; > linux-omap@xxxxxxxxxxxxxxx; David Brownell > Subject: Re: Overo broken with current top of tree > > * Steve Sakoman <sakoman@xxxxxxxxx> [090430 08:10]: > > On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown > <broonie@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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. > > Great. Looks like -rc4 is out, so I'll update our omap tree > to that today, > and we'll get this patch in. > Still observing the problems on OMAP3EVM. My code is at 415f2c76e247f2e6a325621e54f0b1b5dc3669cd + the patch below. bootlog: [snip]--[snip] <6>i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz <6>twl4030: PIH (irq 7) chaining IRQs 368..375 <6>twl4030: power (irq 373) chaining IRQs 376..383 <3>twl4030_gpio: use which platform_data? <6>twl4030: gpio (irq 368) chaining IRQs 384..401 <4>MUX: setup L8_34XX_GPIO63 (0xd80020ce): 0x0118 -> 0x0104 <3>mmci-omap-hs.0: use which platform_data? <3>twl4030_keypad: use which platform_data? <3>twl4030_usb: use which platform_data? <3>twl4030_reg.17: use which platform_data? <6>regulator: VUSB1V5: 1500 mV normal standby <3>twl4030_reg.18: use which platform_data? <6>regulator: VUSB1V8: 1800 mV normal standby <3>twl4030_reg.19: use which platform_data? <6>regulator: VUSB3V1: 3100 mV normal standby <6>i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz <6>i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz <5>SCSI subsystem initialized <6>twl4030_usb twl4030_usb: Initialized TWL4030 USB module <6>usbcore: registered new interface driver usbfs <6>usbcore: registered new interface driver hub <6>usbcore: registered new device driver usb <6>musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 <7>Switched to high resolution mode on CPU 0 <7>musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X)) [snip]--[/snip] <6>omapfb: configured for panel omap3evm <6>omapfb: DISPC version 3.0 initialized <6>omapfb: Framebuffer initialized. Total vram 614400 planes 1 <6>omapfb: Pixclock 25411 kHz hfreq 48.9 kHz vfreq 74.4 Hz <6>Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled <6>serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 Get too many 'funny' chars beyond this point: > Tony > > > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > > > Signed-off-by: Liam Girdwood <lrg@xxxxxxxxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
