Re: Overo broken with current top of tree
On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman sako...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman sako...@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 broo...@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 broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
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? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown broo...@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 sako...@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 broo...@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 broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
* Steve Sakoman sako...@gmail.com [090430 08:10]:
On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown broo...@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 sako...@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 broo...@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 broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Overo broken with current top of tree
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@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 sako...@gmail.com [090430 08:10]: On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown broo...@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 sako...@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] 6i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz 6twl4030: PIH (irq 7) chaining IRQs 368..375 6twl4030: power (irq 373) chaining IRQs 376..383 3twl4030_gpio: use which platform_data? 6twl4030: gpio (irq 368) chaining IRQs 384..401 4MUX: setup L8_34XX_GPIO63 (0xd80020ce): 0x0118 - 0x0104 3mmci-omap-hs.0: use which platform_data? 3twl4030_keypad: use which platform_data? 3twl4030_usb: use which platform_data? 3twl4030_reg.17: use which platform_data? 6regulator: VUSB1V5: 1500 mV normal standby 3twl4030_reg.18: use which platform_data? 6regulator: VUSB1V8: 1800 mV normal standby 3twl4030_reg.19: use which platform_data? 6regulator: VUSB3V1: 3100 mV normal standby 6i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz 6i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz 5SCSI subsystem initialized 6twl4030_usb twl4030_usb: Initialized TWL4030 USB module 6usbcore: registered new interface driver usbfs 6usbcore: registered new interface driver hub 6usbcore: registered new device driver usb 6musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 7Switched to high resolution mode on CPU 0 7musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X)) [snip]--[/snip] 6omapfb: configured for panel omap3evm 6omapfb: DISPC version 3.0 initialized 6omapfb: Framebuffer initialized. Total vram 614400 planes 1 6omapfb: Pixclock 25411 kHz hfreq 48.9 kHz vfreq 74.4 Hz 6Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled 6serial8250.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 broo...@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 broo...@opensource.wolfsonmicro.com Signed-off-by: Liam Girdwood l...@slimlogic.co.uk diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 2f14c16..98c3a74 100644 --- a/drivers
Re: Overo broken with current top of tree
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 10:41 AM, David Brownell davi...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
