* Overo broken with current top of tree @ 2009-04-29 16:03 Steve Sakoman 2009-04-30 9:31 ` Grazvydas Ignotas 0 siblings, 1 reply; 10+ messages in thread From: Steve Sakoman @ 2009-04-29 16:03 UTC (permalink / raw) To: linux-omap@vger.kernel.org I tried an Overo build from the current top of tree and ran into a number of twl4030 platform data errors: 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? set_machine_constraints: invalid 'VUSB1V5' voltage constraints twl4030_reg twl4030_reg.17: can't register VUSB1V5, -22 twl4030_reg: probe of twl4030_reg.17 failed with error -22 twl4030_reg.18: use which platform_data? set_machine_constraints: invalid 'VUSB1V8' voltage constraints twl4030_reg twl4030_reg.18: can't register VUSB1V8, -22 twl4030_reg: probe of twl4030_reg.18 failed with error -22 twl4030_reg.19: use which platform_data? set_machine_constraints: invalid 'VUSB3V1' voltage constraints twl4030_reg twl4030_reg.19: can't register VUSB3V1, -22 twl4030_reg: probe of twl4030_reg.19 failed with error -22 i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz SCSI subsystem initialized twl4030_usb twl4030_usb: ldo init failed Before I go digging, have there been any recent changes in 4030 init that require me to update the Overo board file? Steve ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 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 10:23 ` David Brownell 0 siblings, 2 replies; 10+ messages in thread From: Grazvydas Ignotas @ 2009-04-30 9:31 UTC (permalink / raw) To: Steve Sakoman; +Cc: linux-omap@vger.kernel.org, David Brownell, Mark Brown On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman <sakoman@gmail.com> wrote: > I tried an Overo build from the current top of tree and ran into a > number of twl4030 platform data errors: > > 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? > set_machine_constraints: invalid 'VUSB1V5' voltage constraints > twl4030_reg twl4030_reg.17: can't register VUSB1V5, -22 > twl4030_reg: probe of twl4030_reg.17 failed with error -22 > twl4030_reg.18: use which platform_data? > set_machine_constraints: invalid 'VUSB1V8' voltage constraints > twl4030_reg twl4030_reg.18: can't register VUSB1V8, -22 > twl4030_reg: probe of twl4030_reg.18 failed with error -22 > twl4030_reg.19: use which platform_data? > set_machine_constraints: invalid 'VUSB3V1' voltage constraints > twl4030_reg twl4030_reg.19: can't register VUSB3V1, -22 > twl4030_reg: probe of twl4030_reg.19 failed with error -22 > i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz > SCSI subsystem initialized > twl4030_usb twl4030_usb: ldo init failed > > Before I go digging, have there been any recent changes in 4030 init > that require me to update the Overo board file? I get the same on pandora, although it continues booting fine after that. Maybe regulator folks will comment about regulator errors. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 2009-04-30 9:31 ` Grazvydas Ignotas @ 2009-04-30 10:16 ` Mark Brown 2009-04-30 15:07 ` Steve Sakoman 2009-04-30 10:23 ` David Brownell 1 sibling, 1 reply; 10+ messages in thread From: Mark Brown @ 2009-04-30 10:16 UTC (permalink / raw) To: Grazvydas Ignotas Cc: Steve Sakoman, linux-omap@vger.kernel.org, David Brownell 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: 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 */ ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 2009-04-30 10:16 ` Mark Brown @ 2009-04-30 15:07 ` Steve Sakoman 2009-04-30 15:24 ` Tony Lindgren 2009-04-30 17:41 ` David Brownell 0 siblings, 2 replies; 10+ messages in thread From: Steve Sakoman @ 2009-04-30 15:07 UTC (permalink / raw) To: Mark Brown; +Cc: Grazvydas Ignotas, linux-omap@vger.kernel.org, David Brownell 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 2009-04-30 15:07 ` Steve Sakoman @ 2009-04-30 15:24 ` Tony Lindgren 2009-04-30 15:53 ` Premi, Sanjeev 2009-04-30 17:41 ` David Brownell 1 sibling, 1 reply; 10+ messages in thread From: Tony Lindgren @ 2009-04-30 15:24 UTC (permalink / raw) To: Steve Sakoman Cc: Mark Brown, Grazvydas Ignotas, linux-omap@vger.kernel.org, David Brownell * Steve Sakoman <sakoman@gmail.com> [090430 08:10]: > 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. Great. Looks like -rc4 is out, so I'll update our omap tree to that today, and we'll get this patch in. 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@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 -- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Overo broken with current top of tree 2009-04-30 15:24 ` Tony Lindgren @ 2009-04-30 15:53 ` Premi, Sanjeev 0 siblings, 0 replies; 10+ messages in thread From: Premi, Sanjeev @ 2009-04-30 15:53 UTC (permalink / raw) To: Tony Lindgren, Steve Sakoman Cc: Mark Brown, Grazvydas Ignotas, linux-omap@vger.kernel.org, David Brownell > -----Original Message----- > From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren > Sent: Thursday, April 30, 2009 8:55 PM > To: Steve Sakoman > Cc: Mark Brown; Grazvydas Ignotas; > linux-omap@vger.kernel.org; David Brownell > Subject: Re: Overo broken with current top of tree > > * Steve Sakoman <sakoman@gmail.com> [090430 08:10]: > > 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. > > 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@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 > -- > 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 > > -- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 2009-04-30 15:07 ` Steve Sakoman 2009-04-30 15:24 ` Tony Lindgren @ 2009-04-30 17:41 ` David Brownell 2009-04-30 17:50 ` Steve Sakoman 1 sibling, 1 reply; 10+ messages in thread From: David Brownell @ 2009-04-30 17:41 UTC (permalink / raw) To: Steve Sakoman; +Cc: Mark Brown, Grazvydas Ignotas, linux-omap@vger.kernel.org On Thursday 30 April 2009, Steve Sakoman wrote: > The platform data messages still appear, Those platform_data patches are getting reverted. Ignore the messages for now. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 2009-04-30 17:41 ` David Brownell @ 2009-04-30 17:50 ` Steve Sakoman 2009-04-30 18:07 ` David Brownell 0 siblings, 1 reply; 10+ messages in thread From: Steve Sakoman @ 2009-04-30 17:50 UTC (permalink / raw) To: David Brownell; +Cc: Mark Brown, Grazvydas Ignotas, linux-omap@vger.kernel.org On Thu, Apr 30, 2009 at 10:41 AM, David Brownell <david-b@pacbell.net> wrote: > On Thursday 30 April 2009, Steve Sakoman wrote: >> The platform data messages still appear, > > Those platform_data patches are getting reverted. > Ignore the messages for now. > Will do :-) There seem to be no ill side effects, so it seems safe to do so. I've also noticed that I now get occasional "mmcblk0: retrying using single block read" messages on the serial console. I haven't seen these before. Anyone see anything similar on their setup? Steve ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 2009-04-30 17:50 ` Steve Sakoman @ 2009-04-30 18:07 ` David Brownell 0 siblings, 0 replies; 10+ messages in thread From: David Brownell @ 2009-04-30 18:07 UTC (permalink / raw) To: Steve Sakoman; +Cc: Mark Brown, Grazvydas Ignotas, linux-omap@vger.kernel.org On Thursday 30 April 2009, Steve Sakoman wrote: > I've also noticed that I now get occasional "mmcblk0: retrying using > single block read" messages on the serial console. I haven't seen > these before. Anyone see anything similar on their setup? Yes. -- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Overo broken with current top of tree 2009-04-30 9:31 ` Grazvydas Ignotas 2009-04-30 10:16 ` Mark Brown @ 2009-04-30 10:23 ` David Brownell 1 sibling, 0 replies; 10+ messages in thread From: David Brownell @ 2009-04-30 10:23 UTC (permalink / raw) To: Grazvydas Ignotas; +Cc: Steve Sakoman, linux-omap@vger.kernel.org, Mark Brown On Thursday 30 April 2009, Grazvydas Ignotas wrote: > I get the same on pandora, although it continues booting fine after > that. Maybe regulator folks will comment about regulator errors. Does mainline 3e59091828ed5406c879b899b4257fcef7271e2c resolve it for you? ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-04-30 18:07 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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.