[PATCH 0/2] mx31moboard for 2.6.33-rc1

[PATCH 0/2] mx31moboard for 2.6.33-rc1

[Valentin Longchamp]

I have tested mx31moboard with the first -rc. Here are two patches correcting the current problems. They should go to a next -rc.

1) The patches for usbh support were based on the bad branch, where the platform_devices had been renamed. Now this prevents the mx3 config to build. The first patch reverts to the correct names.

2) The MC13783 voltage regulators with boot_on or always_on enabled hang the kernel at boot. Remove these options from mx31moboard configuration. Sascha, is this a correct behavior or is it a bug ?

Thanks

Val 

[PATCH 1/2] mx31moboard: fix usbh device names

[Valentin Longchamp]

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/mach-mx3/mx31moboard-devboard.c |    2 +-
 arch/arm/mach-mx3/mx31moboard-marxbot.c  |    2 +-
 arch/arm/mach-mx3/mx31moboard.c          |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard-devboard.c b/arch/arm/mach-mx3/mx31moboard-devboard.c
index 8fc624f..438428e 100644
--- a/arch/arm/mach-mx3/mx31moboard-devboard.c
+++ b/arch/arm/mach-mx3/mx31moboard-devboard.c
@@ -179,7 +179,7 @@ static int __init devboard_usbh1_init(void)
 
 	usbh1_pdata.otg = otg;
 
-	return mxc_register_device(&mx31_usbh1, &usbh1_pdata);
+	return mxc_register_device(&mxc_usbh1, &usbh1_pdata);
 }
 
 /*
diff --git a/arch/arm/mach-mx3/mx31moboard-marxbot.c b/arch/arm/mach-mx3/mx31moboard-marxbot.c
index 8acf038..f3123f1 100644
--- a/arch/arm/mach-mx3/mx31moboard-marxbot.c
+++ b/arch/arm/mach-mx3/mx31moboard-marxbot.c
@@ -294,7 +294,7 @@ static int __init marxbot_usbh1_init(void)
 
 	usbh1_pdata.otg = otg;
 
-	return mxc_register_device(&mx31_usbh1, &usbh1_pdata);
+	return mxc_register_device(&mxc_usbh1, &usbh1_pdata);
 }
 
 /*
diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
index f235674..88532b8 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -393,7 +393,7 @@ static int __init moboard_usbh2_init(void)
 	usbh2_pdata.otg = otg_ulpi_create(&mxc_ulpi_access_ops,
 			USB_OTG_DRV_VBUS | USB_OTG_DRV_VBUS_EXT);
 
-	return mxc_register_device(&mx31_usbh2, &usbh2_pdata);
+	return mxc_register_device(&mxc_usbh2, &usbh2_pdata);
 }
 
 
-- 
1.6.3.3

[PATCH 2/2] mx31moboard: boot_on/always_on voltage regulators hang kernel at boot

[Valentin Longchamp]

Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch>
---
 arch/arm/mach-mx3/mx31moboard.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
index 88532b8..b4baf30 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -184,7 +184,7 @@ static struct regulator_init_data sdhc_vreg_data = {
 		.valid_modes_mask = REGULATOR_MODE_NORMAL |
 			REGULATOR_MODE_FAST,
 		.always_on = 0,
-		.boot_on = 1,
+		.boot_on = 0,
 	},
 	.num_consumer_supplies = ARRAY_SIZE(sdhc_consumers),
 	.consumer_supplies = sdhc_consumers,
@@ -206,7 +206,7 @@ static struct regulator_init_data cam_vreg_data = {
 		.valid_modes_mask = REGULATOR_MODE_NORMAL |
 			REGULATOR_MODE_FAST,
 		.always_on = 0,
-		.boot_on = 1,
+		.boot_on = 0,
 	},
 	.num_consumer_supplies = ARRAY_SIZE(cam_consumers),
 	.consumer_supplies = cam_consumers,
-- 
1.6.3.3

[PATCH 0/2] mx31moboard for 2.6.33-rc1

[Alberto Panizzo]

> 2) The MC13783 voltage regulators with boot_on or always_on enabled
> hang the kernel at boot. Remove these options from mx31moboard
> configuration. Sascha, is this a correct behavior or is it a bug ?
> 

Please, enable debug on drivers/spi/imx_spi, drivers/mfd/mc13783-core 
drivers/regulator/mc13783-regulator and drivers/regulator/core 
and let me know what is going on.
I've sent four patches that give voltage selection functionality to 
regulators, but not all are applied at this moment.
I am working on the i.MX31 PDK kernel support, and with those patches
I am able to setup correctly regulators voltages (not modes).

At the moment, the code in kernel can produce a PWGTxDRV lowering 
if you wont to modify something in the mc13783 power-miscellaneous
register.

Alberto!

[PATCH 0/2] mx31moboard for 2.6.33-rc1

[Sascha Hauer]

On Fri, Dec 18, 2009 at 06:11:31PM +0100, Valentin Longchamp wrote:
> I have tested mx31moboard with the first -rc. Here are two patches correcting the current problems. They should go to a next -rc.
> 
> 1) The patches for usbh support were based on the bad branch, where
> the platform_devices had been renamed. Now this prevents the mx3
> config to build. The first patch reverts to the correct names.
> 
> 2) The MC13783 voltage regulators with boot_on or always_on enabled
> hang the kernel at boot. Remove these options from mx31moboard
> configuration. Sascha, is this a correct behavior or is it a bug ?

AFAIK the boot_on indicate the regulator framework that this regulator
is already enabled when the kernel starts. I don't see why this makes
the kernel hang. Can you do a bit more debugging please?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 0/2] mx31moboard for 2.6.33-rc1

[Alberto Panizzo]

Il giorno lun, 21/12/2009 alle 12.17 +0100, Sascha Hauer ha scritto:
> On Fri, Dec 18, 2009 at 06:11:31PM +0100, Valentin Longchamp wrote:
> > I have tested mx31moboard with the first -rc. Here are two patches correcting the current problems. They should go to a next -rc.
> > 
> > 1) The patches for usbh support were based on the bad branch, where
> > the platform_devices had been renamed. Now this prevents the mx3
> > config to build. The first patch reverts to the correct names.
> > 
> > 2) The MC13783 voltage regulators with boot_on or always_on enabled
> > hang the kernel at boot. Remove these options from mx31moboard
> > configuration. Sascha, is this a correct behavior or is it a bug ?
> 
> AFAIK the boot_on indicate the regulator framework that this regulator
> is already enabled when the kernel starts. I don't see why this makes
> the kernel hang. Can you do a bit more debugging please?
> 
> Sascha
> 

The patch that I proposed:
[PATCH 2/4] mfd: mc13783: When probing, unlock the mc13783 before subsystems initialisation.
solve the problem I think.

If you enable the debug output on drivers/mfd/mc13783-core and you see that the
kernel hang on the mc13783 waiting queue, than my patch is for you.

With boot_on = 1 the regulator core ensure also that the regulator is
enabled during probe, so it call the corresponding enable function.
That function utilise the mc13783-API that are still locked.

mc13783-regulator now is probed when mc13783-core register it's regulator
subsystem.

For now that patch (acked by Uwe Kleine-K?nig) is not applied to the mfd tree.

Alberto!

[PATCH 0/2] mx31moboard for 2.6.33-rc1

[Valentin Longchamp]

Alberto Panizzo wrote:
> Il giorno lun, 21/12/2009 alle 12.17 +0100, Sascha Hauer ha scritto:
>> On Fri, Dec 18, 2009 at 06:11:31PM +0100, Valentin Longchamp wrote:
>>> I have tested mx31moboard with the first -rc. Here are two patches correcting the current problems. They should go to a next -rc.
>>>
>>> 1) The patches for usbh support were based on the bad branch, where
>>> the platform_devices had been renamed. Now this prevents the mx3
>>> config to build. The first patch reverts to the correct names.
>>>
>>> 2) The MC13783 voltage regulators with boot_on or always_on enabled
>>> hang the kernel at boot. Remove these options from mx31moboard
>>> configuration. Sascha, is this a correct behavior or is it a bug ?
>> AFAIK the boot_on indicate the regulator framework that this regulator
>> is already enabled when the kernel starts. I don't see why this makes
>> the kernel hang. Can you do a bit more debugging please?
>>
>> Sascha
>>
> 
> The patch that I proposed:
> [PATCH 2/4] mfd: mc13783: When probing, unlock the mc13783 before subsystems initialisation.
> solve the problem I think.
> 
> If you enable the debug output on drivers/mfd/mc13783-core and you see that the
> kernel hang on the mc13783 waiting queue, than my patch is for you.
> 
> With boot_on = 1 the regulator core ensure also that the regulator is
> enabled during probe, so it call the corresponding enable function.
> That function utilise the mc13783-API that are still locked.
> 
> mc13783-regulator now is probed when mc13783-core register it's regulator
> subsystem.
> 
> For now that patch (acked by Uwe Kleine-K?nig) is not applied to the mfd tree.
> 

I confirm what Alberto tells, this patch solves the kernel hang at boot 
for both the boot_on and and always_on flags, avoiding the deadlock 
explained above.

My patch is then be pointless when Alberto's patch gets merged.

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp at epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne