[PATCH] mx31moboard: fix typo

[PATCH] mx31moboard: fix typo

[Robert Schwebel]

Currently, linux-next breaks due to a typo introduced in commit
33c4d91928bea4444b067e620496befbeb87029c

This patch fixes it.

Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: Valentin Longchamp <valentin.longchamp@epfl.ch>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-mx3/mx31moboard.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31moboard.c b/arch/arm/mach-mx3/mx31moboard.c
index 1ec679a..b705291 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -226,7 +226,7 @@ static struct mc13783_regulator_init_data moboard_regulators[] = {
 static struct mc13783_platform_data moboard_pmic = {
 	.regulators = moboard_regulators,
 	.num_regulators = ARRAY_SIZE(moboard_regulators),
-	.flags = MC13783_USE_REGULATOR | MC13783_USE_RTC,
+	.flags = MC13783_USE_REGULATOR | MC13783_USE_RTC |
 		MC13783_USE_ADC,
 };
 
-- 
1.5.6.5

[PATCH] mx31moboard: fix typo

[Robert Schwebel]

On Thu, Dec 03, 2009 at 08:30:34PM +0100, Robert Schwebel wrote:
> Currently, linux-next breaks due to a typo introduced in commit
> 33c4d91928bea4444b067e620496befbeb87029c
> 
> This patch fixes it.

But something else must be missing, I still get this:

arch/arm/mach-mx3/mx31moboard.c: In function 'moboard_usbh2_init':
arch/arm/mach-mx3/mx31moboard.c:395: error: 'mx31_usbh2' undeclared (first use in this function)
arch/arm/mach-mx3/mx31moboard.c:395: error: (Each undeclared identifier is reported only once
arch/arm/mach-mx3/mx31moboard.c:395: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-mx3/mx31moboard.o] Error 1

rsc
-- 
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] mx31moboard: fix typo

[Valentin Longchamp]

Robert Schwebel wrote:
> On Thu, Dec 03, 2009 at 08:30:34PM +0100, Robert Schwebel wrote:
>> Currently, linux-next breaks due to a typo introduced in commit
>> 33c4d91928bea4444b067e620496befbeb87029c
>>
>> This patch fixes it.

Thanks for fixing the typo, I gave me one warning that I had never noticed.

> 
> But something else must be missing, I still get this:
> 
> arch/arm/mach-mx3/mx31moboard.c: In function 'moboard_usbh2_init':
> arch/arm/mach-mx3/mx31moboard.c:395: error: 'mx31_usbh2' undeclared (first use in this function)
> arch/arm/mach-mx3/mx31moboard.c:395: error: (Each undeclared identifier is reported only once
> arch/arm/mach-mx3/mx31moboard.c:395: error: for each function it appears in.)
> make[1]: *** [arch/arm/mach-mx3/mx31moboard.o] Error 1
> 

This comes from the usb host support for mx31 that should come with 
2.6.33. Does linux-next already include these patches ?

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

[PATCH] mx31moboard: fix typo

[Valentin Longchamp]

Valentin Longchamp wrote:
> Robert Schwebel wrote:
> 
>> But something else must be missing, I still get this:
>>
>> arch/arm/mach-mx3/mx31moboard.c: In function 'moboard_usbh2_init':
>> arch/arm/mach-mx3/mx31moboard.c:395: error: 'mx31_usbh2' undeclared (first use in this function)
>> arch/arm/mach-mx3/mx31moboard.c:395: error: (Each undeclared identifier is reported only once
>> arch/arm/mach-mx3/mx31moboard.c:395: error: for each function it appears in.)
>> make[1]: *** [arch/arm/mach-mx3/mx31moboard.o] Error 1
>>
> 
> This comes from the usb host support for mx31 that should come with 
> 2.6.33. Does linux-next already include these patches ?
> 

Hum, sorry, my bad, this was based on mxc_master_*pu* (don't ask me why, 
maybe not enough coffee). This branch includes the changes for using soc 
specific defines by Sascha.

Sacha, any chance these hit mainline/next soon ? Or do you want me to 
send correcting patch ?

Thanks

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

[PATCH] mx31moboard: fix typo

[Sascha Hauer]

On Fri, Dec 04, 2009 at 12:14:04PM +0100, Valentin Longchamp wrote:
> Valentin Longchamp wrote:
>> Robert Schwebel wrote:
>>
>>> But something else must be missing, I still get this:
>>>
>>> arch/arm/mach-mx3/mx31moboard.c: In function 'moboard_usbh2_init':
>>> arch/arm/mach-mx3/mx31moboard.c:395: error: 'mx31_usbh2' undeclared (first use in this function)
>>> arch/arm/mach-mx3/mx31moboard.c:395: error: (Each undeclared identifier is reported only once
>>> arch/arm/mach-mx3/mx31moboard.c:395: error: for each function it appears in.)
>>> make[1]: *** [arch/arm/mach-mx3/mx31moboard.o] Error 1
>>>
>>
>> This comes from the usb host support for mx31 that should come with  
>> 2.6.33. Does linux-next already include these patches ?
>>
>
> Hum, sorry, my bad, this was based on mxc_master_*pu* (don't ask me why,  
> maybe not enough coffee). This branch includes the changes for using soc  
> specific defines by Sascha.
>
> Sacha, any chance these hit mainline/next soon ? Or do you want me to  
> send correcting patch ?

Please send a fixup patch.

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 1/1] 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 1ec679a..fab9f3f 100644
--- a/arch/arm/mach-mx3/mx31moboard.c
+++ b/arch/arm/mach-mx3/mx31moboard.c
@@ -392,7 +392,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] mx31moboard: fix typo

[Guennadi Liakhovetski]

On Thu, 3 Dec 2009, Robert Schwebel wrote:

> On Thu, Dec 03, 2009 at 08:30:34PM +0100, Robert Schwebel wrote:
> > Currently, linux-next breaks due to a typo introduced in commit
> > 33c4d91928bea4444b067e620496befbeb87029c
> > 
> > This patch fixes it.
> 
> But something else must be missing, I still get this:

...to second that, yesterday's next also locks up hard on boot on pcm037. 
.config available on request.

Thanks
Guennadi

> 
> arch/arm/mach-mx3/mx31moboard.c: In function 'moboard_usbh2_init':
> arch/arm/mach-mx3/mx31moboard.c:395: error: 'mx31_usbh2' undeclared (first use in this function)
> arch/arm/mach-mx3/mx31moboard.c:395: error: (Each undeclared identifier is reported only once
> arch/arm/mach-mx3/mx31moboard.c:395: error: for each function it appears in.)
> make[1]: *** [arch/arm/mach-mx3/mx31moboard.o] Error 1
> 
> rsc
> -- 
> 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 |
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH] mx31moboard: fix typo

[Valentin Longchamp]

Guennadi Liakhovetski wrote:
> On Thu, 3 Dec 2009, Robert Schwebel wrote:
> 
>> On Thu, Dec 03, 2009 at 08:30:34PM +0100, Robert Schwebel wrote:
>>> Currently, linux-next breaks due to a typo introduced in commit
>>> 33c4d91928bea4444b067e620496befbeb87029c
>>>
>>> This patch fixes it.
>> But something else must be missing, I still get this:
> 
> ...to second that, yesterday's next also locks up hard on boot on pcm037. 
> .config available on request.
> 

Same problem here. As a matter of fact, it comes from the mxc-master 
branch. I have bisected out the culprit:

http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=52939c03e53b151848da9e83fd839bddfda29e78

It seems conform with the lock syndrom: very early at boot right after 
Uncompessing Linux and before any other message.

The proc stalls on this read:
srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);

Maybe Guennadi and I have silicon revisions that do not work well with 
this patch (because I assume it worked well for Daniel).

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

[PATCH] mx31moboard: fix typo

[Daniel Mack]

On Fri, Dec 04, 2009 at 06:30:37PM +0100, Valentin Longchamp wrote:
> Guennadi Liakhovetski wrote:
> >...to second that, yesterday's next also locks up hard on boot on
> >pcm037. .config available on request.
> >
> 
> Same problem here. As a matter of fact, it comes from the mxc-master
> branch. I have bisected out the culprit:
> 
> http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=52939c03e53b151848da9e83fd839bddfda29e78
> 
> It seems conform with the lock syndrom: very early at boot right
> after Uncompessing Linux and before any other message.
> 
> The proc stalls on this read:
> srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);
> 
> Maybe Guennadi and I have silicon revisions that do not work well
> with this patch (because I assume it worked well for Daniel).

Grmpf. Yes, it does work right on my LiteKit board, and the reference
manual reads like the register is there for a very long time (as it has
possible values for very old silicon revisions).

Could you double check whether the clock is running? The only thing I can
think of is differences in the bootloaders. I still have the proprietary
'losh' running here, which I have no sources for.

Daniel

[PATCH] mx31moboard: fix typo

[Valentin Longchamp]

Daniel Mack wrote:
> On Fri, Dec 04, 2009 at 06:30:37PM +0100, Valentin Longchamp wrote:
>> Guennadi Liakhovetski wrote:
>>> ...to second that, yesterday's next also locks up hard on boot on
>>> pcm037. .config available on request.
>>>
>> Same problem here. As a matter of fact, it comes from the mxc-master
>> branch. I have bisected out the culprit:
>>
>> http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=52939c03e53b151848da9e83fd839bddfda29e78
>>
>> It seems conform with the lock syndrom: very early at boot right
>> after Uncompessing Linux and before any other message.
>>
>> The proc stalls on this read:
>> srev = __raw_readl(IO_ADDRESS(IIM_BASE_ADDR) + MXC_IIMSREV);
>>
>> Maybe Guennadi and I have silicon revisions that do not work well
>> with this patch (because I assume it worked well for Daniel).
> 
> Grmpf. Yes, it does work right on my LiteKit board, and the reference
> manual reads like the register is there for a very long time (as it has
> possible values for very old silicon revisions).

Well, there are not a lot of information about the IIM in the reference 
manual (only Tables 13-1 for the different fuses and 13-2 for the 
silicon revisions). I wanted to check for the registers to find maybe a 
problem, but found nothing more

> 
> Could you double check whether the clock is running? The only thing I can
> think of is differences in the bootloaders. I still have the proprietary
> 'losh' running here, which I have no sources for.
> 

The clock is running (well, at least the parent ipg_clk and the gating 
is configured for the clock running, thanks to clk_enable(&iim_clk);

About the bootloader, on our boards we have redboot, adapted from the 
release Freescale did for the ADS. So it may be a bootloader issue. What 
could be missing in my bootloader that makes this read fail ?

I would say that maybe someting the EMI or SPBA configuration is missing 
so that I can access the addresses in this range. Any ideas ?

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

[PATCH] mx31moboard: fix typo

[Daniel Mack]

On Wed, Dec 09, 2009 at 01:44:50PM +0100, Valentin Longchamp wrote:
> Daniel Mack wrote:
> >Could you double check whether the clock is running? The only thing I can
> >think of is differences in the bootloaders. I still have the proprietary
> >'losh' running here, which I have no sources for.
> >
> 
> The clock is running (well, at least the parent ipg_clk and the
> gating is configured for the clock running, thanks to
> clk_enable(&iim_clk);
> 
> About the bootloader, on our boards we have redboot, adapted from
> the release Freescale did for the ADS. So it may be a bootloader
> issue. What could be missing in my bootloader that makes this read
> fail ?
> 
> I would say that maybe someting the EMI or SPBA configuration is
> missing so that I can access the addresses in this range. Any ideas
> ?

I don't, sorry. I was hoping anyone else has more documentation - at
least the reference manual makes me believe there is more that just that
2 pages.

In worst case we need to revert that patch, but I would like to avoid
that.

Daniel