OMAP34xx

Does someone want to try building and running Linux on (eg) an OMAP34xx platform before I post my next email message on this subject, and maybe send me a bunch of patches required to fix stuff, to be applied to my tree _and_ _then_ forwarded to Linus next Friday.

So, think of this as your last chance, and you'll get the picture about how pissed off I am with the - yet again - current poor state of OMAP in mainline, which seems to happen every merge window.

Consider this: when Linus started using a PowerPC platform, the PowerPC people quickly realized that pushing patches upstream which broke stuff was a really bad idea, because they got publically flamed for such actions especially when stuff was not obviously tested.

This is no different... and this is _not_ my original email which I have queued up with the real hot flames in over this. This is the toned down version. The flames won't get sent if OMAP gets fixed quickly - and if testing improves to stop this constant cycle of regressions at every merge window.

Quoted 14 lines · Russell King - ARM Linux

Does someone want to try building and running Linux on (eg) an OMAP34xx platform before I post my next email message on this subject, and maybe send me a bunch of patches required to fix stuff, to be applied to my tree _and_ _then_ forwarded to Linus next Friday.

So, think of this as your last chance, and you'll get the picture about how pissed off I am with the - yet again - current poor state of OMAP in mainline, which seems to happen every merge window.

Consider this: when Linus started using a PowerPC platform, the PowerPC people quickly realized that pushing patches upstream which broke stuff was a really bad idea, because they got publically flamed for such actions especially when stuff was not obviously tested.

Quoted 5 lines

This is no different... and this is _not_ my original email which I have queued up with the real hot flames in over this.  This is the toned down version.  The flames won't get sent if OMAP gets fixed quickly - and if testing improves to stop this constant cycle of regressions at every merge window.

Do you have the patches applied already queued up in arm-soc fixes branch?

Quoted 14 lines · Russell King - ARM Linux

Does someone want to try building and running Linux on (eg) an OMAP34xx platform before I post my next email message on this subject, and maybe send me a bunch of patches required to fix stuff, to be applied to my tree _and_ _then_ forwarded to Linus next Friday.

So, think of this as your last chance, and you'll get the picture about how pissed off I am with the - yet again - current poor state of OMAP in mainline, which seems to happen every merge window.

Consider this: when Linus started using a PowerPC platform, the PowerPC people quickly realized that pushing patches upstream which broke stuff was a really bad idea, because they got publically flamed for such actions especially when stuff was not obviously tested.

Quoted 5 lines

This is no different... and this is _not_ my original email which I have queued up with the real hot flames in over this. This is the toned down version. The flames won't get sent if OMAP gets fixed quickly - and if testing improves to stop this constant cycle of regressions at every merge window.

Do you have the patches applied already queued up in arm-soc fixes branch?

And OMAP4 doesn't build. Fixing the build error in prm44xx.c (which is virtually the same as the OMAP3 build error in its prm file) gets us to a buildable state, but... it silently fails to boot.

arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)

Quoted 5 lines · Russell King - ARM Linux

And OMAP4 doesn't build. Fixing the build error in prm44xx.c (which is virtually the same as the OMAP3 build error in its prm file) gets us to a buildable state, but... it silently fails to boot.

arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)

BTW, I can tell you why you don't see this error - you're building with DT enabled, which gives you this header path to those definitions:

arch/arm/mach-omap2/prm44xx.c
arch/arm/mach-omap2/common.h
plat/common.h
plat/i2c.h

    linux/i2c.h
     linux/of.h
      asm/prom.h
       asm/irq.h
        mach/irqs.h
         plat/irqs.h
          plat/irqs-44xx.h

which, I think you'll agree, is a recipe for disaster if any one of those decides not to include its child at some point either via configuration or via mere deletion of an include.

Another problem oopses the kernel at boot in the voltage domain code, which I suspect this has never been boot tested on OMAP34xx CPUs:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (3.3.0-rc2+ #204)
PC is at omap_vp_init+0x5c/0x15c
LR is at omap_vp_init+0x58/0x15c

Quoted 4 lines · Russell King - ARM Linux

Another problem oopses the kernel at boot in the voltage domain code, which I suspect this has never been boot tested on OMAP34xx CPUs:

omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc

Quoted 8 lines

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (3.3.0-rc2+ #204)
PC is at omap_vp_init+0x5c/0x15c
LR is at omap_vp_init+0x58/0x15c

I've got hit by this too, and it also seems to be DT related, because if you don't select CONFIG_USE_OF, you lose TWL4030_CORE, which results in omap_vp errors and NULL dereference. TWL4030_CORE was made to depend on IRQ_DOMAIN, and that is selected by USE_OF or ARM_GIC. I guess everyone here builds with USE_OF, but maybe ARCH_OMAP3 should select ARM_GIC?

Quoted 15 lines · Tony Lindgren

Quoted 14 lines · Russell King - ARM Linux

Does someone want to try building and running Linux on (eg) an OMAP34xx platform before I post my next email message on this subject, and maybe send me a bunch of patches required to fix stuff, to be applied to my tree _and_ _then_ forwarded to Linus next Friday.

So, think of this as your last chance, and you'll get the picture about how pissed off I am with the - yet again - current poor state of OMAP in mainline, which seems to happen every merge window.

Consider this: when Linus started using a PowerPC platform, the PowerPC people quickly realized that pushing patches upstream which broke stuff was a really bad idea, because they got publically flamed for such actions especially when stuff was not obviously tested.

Quoted 8 lines

Quoted 5 lines

This is no different... and this is _not_ my original email which I have queued up with the real hot flames in over this. This is the toned down version. The flames won't get sent if OMAP gets fixed quickly - and if testing improves to stop this constant cycle of regressions at every merge window.

Do you have the patches applied already queued up in arm-soc fixes branch?

It really doesn't make much difference - the only improvement I see in the big collection of issues I have with OMAP this time around is one build error is gone. There's _far_ _far_ bigger problems in the OMAP code this time.

I'm seriously considering requesting that all OMAP changes for the merge window come through me rather than arm-soc, so that I can boot and build test them before the merge window opens, and we can cut down on this repetitive cycle of build (and boot) breakage at every merge window.

One problem isn't yours to solve (the requirement for regulators for the SMSC network driver which has appeared.)

Another problem (some build errors for OMAP3) do seem to be solved, but not the section mismatch warnings. They're easy to verify before code gets pushed anywhere upstream, especially if you're doing one giant OMAP build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build configuration. Refuse patches which introduce section mismatches - at least without an explanation backing up why they do.

My OMAP3 and OMAP4 configurations spit out these - I've not even tried my OMAP2 configuration yet:

Another problem oopses the kernel at boot in the voltage domain code, which I suspect this has never been boot tested on OMAP34xx CPUs:

And OMAP4 doesn't build. Fixing the build error in prm44xx.c (which is virtually the same as the OMAP3 build error in its prm file) gets us to a buildable state, but... it silently fails to boot.

arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)

So, a slight improvement, but overall no material forward progress in terms of things booting.

And, compared to my previous testing, the OMAP state is worse than ever as this time, even with your first round of fixes, all my OMAP platforms are pretty broken.

Quoted 4 lines · Russell King - ARM Linux

I'm seriously considering requesting that all OMAP changes for the merge window come through me rather than arm-soc, so that I can boot and build test them before the merge window opens, and we can cut down on this repetitive cycle of build (and boot) breakage at every merge window.

I agree it would be nice to see these issues earlier. I build and boot test every patch I merge, but mostly with omap2plus_defconfig as that does the job for all the boards I have with a single zImage.

Looks like the issues you're seeing are related to .config settings.

How about let's plan on testing your .configs with for-next before the next merge window?

Quoted 6 lines · Tony Lindgren

Quoted 4 lines · Russell King - ARM Linux

I'm seriously considering requesting that all OMAP changes for the merge window come through me rather than arm-soc, so that I can boot and build test them before the merge window opens, and we can cut down on this repetitive cycle of build (and boot) breakage at every merge window.

Quoted 8 lines

I agree it would be nice to see these issues earlier. I build and boot test every patch I merge, but mostly with omap2plus_defconfig as that does the job for all the boards I have with a single zImage.

Looks like the issues you're seeing are related to .config settings.

How about let's plan on testing your .configs with for-next before the next merge window?

I was thinking about something more than just a build-test, because that's just a part of the problem.

Let me make it clear what my motivation here is (before someone starts making any accusations).

There is a view widely held that the mainline OMAP kernels are in a pretty poor shape when it comes to people being buildable (I've been told so.) That reflects my experience each cycle when I try to test a mainline OMAP kernel - and I invariably encounter build or boot problems of various degrees.

What I would _prefer_ to see is that your tree gets build _and_ boot tested by people in the OMAP community with a range of configurations, and any build or boot problems get reported back in a timely manner so that those problems can be solved before the tree goes to arm-soc.

Obviously, some of that does happen, but it's clearly not enough as we keep going around this loop at every merge window where there's breakage each time, there isn't enough of it. So, we need a different solution to this.

So, I was thinking about pulling your tree, building and booting it _and_ requiring it to pass before it goes to mainline. Yes, that's pretty drastic, but I think it's about the only way to ensure that the amount of regressions are reduced down to an acceptable level.

Let's be clear - I'm not talking about the pulls that you'd send to Arnd and Olof for fixes during or after the merge window. I'm talking about the merge window stuff only - because that seems to be where most of the breakage happens.

I've been wondering whether I could set something up which did this all automatically - maybe running a build overnight and then automatically boot testing it and logging the results - including running some userspace testing. One of the issues I'd face is that my current build machine is the laptop, which isn't aways available to run the builds each day.

But... things are complicated by the OMAP boards having USB to serial devices on them rather than standard RS232, which rather limits what I can do to automate testing with them, especially as others require a USB socket as a source of power to run themselves.

Another problem (some build errors for OMAP3) do seem to be solved, but not the section mismatch warnings. They're easy to verify before code gets pushed anywhere upstream, especially if you're doing one giant OMAP build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build configuration. Refuse patches which introduce section mismatches - at least without an explanation backing up why they do.

My OMAP3 and OMAP4 configurations spit out these - I've not even tried my OMAP2 configuration yet:

WARNING: arch/arm/mach-omap2/built-in.o(.text+0xeae8):
Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown)
The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata annotation or the annotation of (unknown) is wrong.

Signed-off-by Igor Grinberg <[email protected]>

---
Sorry about this one. I fixed similar problem for cm-t3517 a while ago, but somehow missed cm-t35. Thanks for spotting.
Probably enabling the CONFIG_DEBUG_SECTION_MISMATCH in defconfigs can raise people awareness for this.

 arch/arm/mach-omap2/board-cm-t35.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

arch/arm/mach-omap2/board-cm-t35.c +1 -1

index d839c05..a8cedbe 100644
@@ -436,7 +436,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
 	.reset_gpio_port[2]  = -EINVAL
 };
 
-static void cm_t35_init_usbh(void)
+static void  __init cm_t35_init_usbh(void)
 {
 	int err;
 

Signature · 1 line

1.7.3.4

This patch updates omapX_defconfig to 3.3-rc1 and enables the CONFIG_DEBUG_SECTION_MISMATCH.

The update is done by:
1) make mrproper && make omapX_defconfig
2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
3) make savedefconfig
4) cp defconfig arch/arm/configs/omapX_defconfig

Signed-off-by Igor Grinberg <[email protected]>

---
After updating omap1_defconfig,
there are several section mismatch warnings seen. Hopefully, I will have time to fix those tomorrow (unless someone will be kind enough to fix them before me). The mismatches are:

Quoted 2 lines · Igor Grinberg

This patch updates omapX_defconfig to 3.3-rc1 and enables the CONFIG_DEBUG_SECTION_MISMATCH.

You shouldn't enable this in the kernel supplied defconfigs.

Quoted 7 lines

The update is done by:
1) make mrproper && make omapX_defconfig
2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
3) make savedefconfig
4) cp defconfig arch/arm/configs/omapX_defconfig

Quoted 7 lines

Signed-off-by Igor Grinberg <[email protected]>

---
After updating omap1_defconfig,
there are several section mismatch warnings seen. Hopefully, I will have time to fix those tomorrow (unless someone will be kind enough to fix them before me). The mismatches are:

The correct way is to build with:

make ... CONFIG_DEBUG_SECTION_MISMATCH=y

or set it in your private configuration.

Quoted 2 lines · Igor Grinberg

This patch updates omapX_defconfig to 3.3-rc1 and enables the CONFIG_DEBUG_SECTION_MISMATCH.

You shouldn't enable this in the kernel supplied defconfigs.

Quoted 6 lines

The update is done by:
1) make mrproper && make omapX_defconfig
2) Enable the CONFIG_DEBUG_SECTION_MISMATCH
3) make savedefconfig
4) cp defconfig arch/arm/configs/omapX_defconfig

Quoted 7 lines

Signed-off-by Igor Grinberg <[email protected]>

---
After updating omap1_defconfig,
there are several section mismatch warnings seen. Hopefully, I will have time to fix those tomorrow (unless someone will be kind enough to fix them before me). The mismatches are:

The correct way is to build with:

make ... CONFIG_DEBUG_SECTION_MISMATCH=y

or set it in your private configuration.

...
After updating omap1_defconfig,
there are several section mismatch warnings seen. Hopefully, I will have time to fix those tomorrow (unless someone will be kind enough to fix them before me).

The mismatches are:

WARNING: vmlinux.o(.data+0xb7e4): Section mismatch in reference from the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch1_gpio_device references the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xb8f4): Section mismatch in reference from the variable latch1_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch1_gpio_device references the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xb974): Section mismatch in reference from the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch2_gpio_device references the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xba84): Section mismatch in reference from the variable latch2_gpio_device to the (unknown reference) .init.rodata:(unknown) The variable latch2_gpio_device references the (unknown reference) __initconst (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

WARNING: vmlinux.o(.data+0xbb04): Section mismatch in reference from the variable ams_delta_kp_device to the (unknown reference) .init.data:(unknown) The variable ams_delta_kp_device references the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

The main purpose of this patch is to fix several section mismatch warnings from the board file and a few board specific drivers, introduced mostly with recent Amstrad Delta patch series, some of them rising up only when building with CONFIG_MODULES not set.

While being at it, section assignments of all init data found in the board file have been revised and hopefully optimised.

Created and tested on top of current linux-omap/omap1, commit 967809bd7faf71ddc29c8081e0f21db8b201a0f4.

Signed-off-by Janusz Krzysztofik <[email protected]>

---
 arch/arm/mach-omap1/board-ams-delta.c |   35 +++++++++++++++++----------------
 drivers/input/serio/ams_delta_serio.c |    2 +-
 drivers/mtd/nand/ams-delta.c          |    2 +-
 drivers/video/omap/lcd_ams_delta.c    |    2 +-
 4 files changed, 21 insertions(+), 20 deletions(-)

arch/arm/mach-omap1/board-ams-delta.c +0 -0

index 87b1303..dc2455f 100644

arch/arm/mach-omap1/board-ams-delta.c +3 -3

 	.register_host	= 1,
 	.hmc_mode	= 16,
 	.pins[0]	= 2,
 };
 
-static struct omap_board_config_kernel ams_delta_config[] __initdata = {
+static struct omap_board_config_kernel ams_delta_config[] __initconst = {
 	{ OMAP_TAG_LCD,		&ams_delta_lcd_config },
 };
 

@@ -181,7 +181,7 @@ static struct bgpio_pdata latch1_pdata __initconst = {
 	.ngpio	= LATCH1_NGPIO,
 };
 
-static struct platform_device latch1_gpio_device = {
+static struct platform_device latch1_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 0,
 	.resource	= latch1_resources,

@@ -205,7 +205,7 @@ static struct bgpio_pdata latch2_pdata __initconst = {
 	.ngpio	= AMS_DELTA_LATCH2_NGPIO,
 };
 
-static struct platform_device latch2_gpio_device = {
+static struct platform_device latch2_gpio_device __refdata = {
 	.name		= "basic-mmio-gpio",
 	.id		= 1,
 	.resource	= latch2_resources,

arch/arm/mach-omap1/board-ams-delta.c +1 -1

 	.rows		= 8,
 	.cols		= 8,
 	.keymap_data	= &ams_delta_keymap_data,
 	.delay		= 9,
 };
 
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __refdata = {
 	.name		= "omap-keypad",
 	.id		= -1,
 	.dev		= {

arch/arm/mach-omap1/board-ams-delta.c +1 -1

 	.bus_id         = 0,	/* OMAP1 SoC camera bus */
 	.i2c_adapter_id = 1,
 	.board_info     = &ams_delta_camera_board_info[0],

@@ -395,7 +396,7 @@ static struct soc_camera_link ams_delta_iclink = {
 	.power		= ams_delta_camera_power,
 };
 
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __refdata = {
 	.name   = "soc-camera-pdrv",
 	.id     = 0,
 	.dev    = {

arch/arm/mach-omap1/board-ams-delta.c +1 -1

 	{
 		.membase	= IOMEM(MODEM_VIRT),
 		.mapbase	= MODEM_PHYS,

@@ -473,7 +474,7 @@ static struct plat_serial8250_port ams_delta_modem_ports[] = {
 	{ },
 };
 
-static struct platform_device ams_delta_modem_device = {
+static struct platform_device ams_delta_modem_device __refdata = {
 	.name	= "serial8250",
 	.id	= PLAT8250_DEV_PLATFORM1,
 	.dev		= {

There is no optimisation to adding __refdata to stuff. That's screaming that you have lots of bugs here.

arch/arm/mach-omap1/board-ams-delta.c static const unsigned int ams_delta_keymap[] = { · line 129

Quoted 2 lines

arch/arm/mach-omap1/board-ams-delta.c +1 -1

-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {

You're not making this comst so don't change it to __initconst.

arch/arm/mach-omap1/board-ams-delta.c static struct map_desc ams_delta_io_desc[] __initdata = { · line 153

Quoted 2 lines

arch/arm/mach-omap1/board-ams-delta.c +1 -1

-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {

This change probably adds a bug. Are you sure this will never be used outside init context?

Quoted 3 lines

(quoted diff) +1 -1

-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module

= {

Even if you don't have modules enabled, have you checked whether the driver can be bound and unbound via /sys/bus/platform/driver/<name>/{bind,unbind} ?

I suspect this is a bug.

Quoted 3 lines

(quoted diff) +1 -1

-static struct resource ams_delta_nand_resources[] = {
+static struct resource ams_delta_nand_resources[] __initconst_or_module

= {

This change definitely adds a bug. The resources are _used_ _all_ _the_ _time_ _the_ _device_ _is_ _registered_. Try catting /proc/iomem after boot.

arch/arm/mach-omap1/board-ams-delta.c static struct gpio_led_platform_data leds_pdata __initconst = { · line 367

Quoted 3 lines

arch/arm/mach-omap1/board-ams-delta.c +2 -1

-static struct i2c_board_info ams_delta_camera_board_info[] = {
+static struct i2c_board_info __initconst_or_module
+ams_delta_camera_board_info[] = {

No. It's

static struct foo blah[] __whatever_init_attribute

not

static struct foo __whatever_init_attribute blah[]

I've no idea where this fucked idea came from but it's something that's wasting a lot of review time with complaints like this about it.

Quoted 3 lines

(quoted diff) +1 -1

-static struct soc_camera_link ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initconst_or_module =

{

Probably buggy.

arch/arm/mach-omap1/board-ams-delta.c static struct omap1_cam_platform_data ams_delta_camera_platform_data = { · line 412

Quoted 2 lines

arch/arm/mach-omap1/board-ams-delta.c +1 -1

-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {

Missing const. If you can't const it, don't put it in __initconst.

Quoted 4 lines · On Thursday 09 of February 2012 14:48:53 Russell King - ARM Linux wrote:

arch/arm/mach-omap1/board-ams-delta.c static const unsigned int ams_delta_keymap[] = { · line 129

Quoted 2 lines

arch/arm/mach-omap1/board-ams-delta.c +1 -1

-static struct map_desc ams_delta_io_desc[] __initdata = {
+static struct map_desc ams_delta_io_desc[] __initconst = {

You're not making this comst so don't change it to __initconst.

OK, however, I think there must be a bug in gcc, otherwise it should probably never accept such wrong constructs, while sometimes it does (not only mine, see [1]).

Quoted 5 lines

arch/arm/mach-omap1/board-ams-delta.c static struct map_desc ams_delta_io_desc[] __initdata = { · line 153

Quoted 2 lines

arch/arm/mach-omap1/board-ams-delta.c +1 -1

-static struct omap_lcd_config ams_delta_lcd_config = {
+static struct omap_lcd_config ams_delta_lcd_config __initconst = {

This change probably adds a bug. Are you sure this will never be used outside init context?

I may be wrong, but before I've changed this, and now once again, I've verified that a copy of this data is made inside __init omap_init_fb() by means of a structure assignment operation.

Quoted 6 lines

Quoted 3 lines

(quoted diff) +1 -1

-static struct omap_usb_config ams_delta_usb_config __initdata = {
+static struct omap_usb_config ams_delta_usb_config __initdata_or_module

= {

Even if you don't have modules enabled, have you checked whether the driver can be bound and unbound via /sys/bus/platform/driver/<name>/{bind,unbind} ?

No, I didn't even think of it, I am afraid.

Quoted 1 line

I suspect this is a bug.

Indeed, that data is not copied on init, only pointed to, moreover, the ohci-omap driver provides bind/unbind opearations.

BTW, what are those bind/unbind operations intended for in case of a driver dedicated to a non-hotplugable SoC hardware exclusively?

Quoted 4 lines

arch/arm/mach-omap1/board-ams-delta.c static struct omap1_cam_platform_data ams_delta_camera_platform_data = { · line 412

Quoted 2 lines

arch/arm/mach-omap1/board-ams-delta.c +1 -1

-static struct platform_device *ams_delta_devices[] __initdata = {
+static struct platform_device *ams_delta_devices[] __initconst = {

Missing const. If you can't const it, don't put it in __initconst.

I gave up trying to use both const and __initconst together after my gcc-4.2.4 (and not only mine, see [1], [2]) refused to accept such constructs a few times. Now I see that this false reporting may probably happen in presence of other incorrect uses of __initconst without const or __initdata with const.

Quoted 10 lines · Russell King - ARM Linux

Another problem (some build errors for OMAP3) do seem to be solved, but not the section mismatch warnings. They're easy to verify before code gets pushed anywhere upstream, especially if you're doing one giant OMAP build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build configuration. Refuse patches which introduce section mismatches - at least without an explanation backing up why they do.

My OMAP3 and OMAP4 configurations spit out these - I've not even tried my OMAP2 configuration yet:

Weird. The warnings you're seeing all seem valid to me, but I'm not seeing any the section warnings with the following compilers I have:

gcc version 4.3.5 (Debian 4.3.5-4)
gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70)

I see _different_ warnings if I compile with an older gcc:
gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)

Any ideas why that would be?

The only warnings I see are:

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19a4): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19a8): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19ac): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19b0): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x19b4): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: arch/arm/mach-omap2/built-in.o(.text+0x12b70): Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown) The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c424): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c428): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c42c): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c430): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x1c434): Section mismatch in reference from the function omap_serial_fill_default_pads() to the (unknown reference) .init.data:(unknown) The function omap_serial_fill_default_pads() references
the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

WARNING: vmlinux.o(.text+0x2d5f0): Section mismatch in reference from the function cm_t35_init_usbh() to the (unknown reference) .init.data:(unknown) The function cm_t35_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t35_init_usbh lacks a __initdata
annotation or the annotation of (unknown) is wrong.

Quoted 19 lines · Tony Lindgren

Quoted 10 lines · Russell King - ARM Linux

Another problem (some build errors for OMAP3) do seem to be solved, but not the section mismatch warnings. They're easy to verify before code gets pushed anywhere upstream, especially if you're doing one giant OMAP build - just enable CONFIG_DEBUG_SECTION_MISMATCH in your build configuration. Refuse patches which introduce section mismatches - at least without an explanation backing up why they do.

My OMAP3 and OMAP4 configurations spit out these - I've not even tried my OMAP2 configuration yet:

Weird. The warnings you're seeing all seem valid to me, but I'm not seeing any the section warnings with the following compilers I have:

gcc version 4.3.5 (Debian 4.3.5-4)
gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70)

Quoted 4 lines

I see _different_ warnings if I compile with an older gcc:
gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)

Any ideas why that would be?

Different inlining behaviour maybe? I'm using stock gcc 4.3.5 here.

If I look at this warning:

WARNING: vmlinux.o(.text+0x1c434): Section mismatch in reference from the fun$> The function omap_serial_fill_default_pads() references the (unknown reference) __initdata (unknown).
This is often because omap_serial_fill_default_pads lacks a __initdata
annotation or the annotation of (unknown) is wrong.

on OMAP3, where CONFIG_OMAP_MUX=y and CONFIG_CC_OPTIMIZE_FOR_SIZE=y, then, the reason I don't get that warning is because omap_serial_fill_default_pads() gets folded into omap_serial_board_init() for me. There's not much which can be done to stop that thing happening.

However, the fact that you're not finding stuff like the reference from

static int __devinit
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)

to:

void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)

between two separate files is very worrying, and does indicate that something is broken - there's no way that the compiler could 'optimize' this by folding twl4030_power_init() into twl_probe() between the two files.

In any case, here's my current (tested) patch unbreaking OMAP as a whole, not only for all these section mismatches but the more fundamental issues like the broken serial ports on OMAP3 and the irq domain buggeration too.

This leaves one section mismatch for me in the OMAP hotplug code.

arch/arm/mach-omap2/hsmmc.c +3 -3

@@ -293,8 +293,8 @@ static inline void omap_hsmmc_mux(struct omap_mmc_platform_data *mmc_controller,
 	}
 }
 
-static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
-					struct omap_mmc_platform_data *mmc)
+static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
+				 struct omap_mmc_platform_data *mmc)
 {
 	char *hc_name;
 

@@ -430,7 +430,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
 
 #define MAX_OMAP_MMC_HWMOD_NAME_LEN		16
 
-void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
+void omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 {
 	struct omap_hwmod *oh;
 	struct platform_device *pdev;

arch/arm/mach-omap2/mux.c +9 -9

@@ -100,8 +100,8 @@ void omap_mux_write_array(struct omap_mux_partition *partition,
 
 static char *omap_mux_options;
 
-static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
-				      int gpio, int val)
+static int _omap_mux_init_gpio(struct omap_mux_partition *partition,
+			       int gpio, int val)
 {
 	struct omap_mux_entry *e;
 	struct omap_mux *gpio_mux = NULL;

@@ -145,7 +145,7 @@ static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
 	return 0;
 }
 
-int __init omap_mux_init_gpio(int gpio, int val)
+int omap_mux_init_gpio(int gpio, int val)
 {
 	struct omap_mux_partition *partition;
 	int ret;

@@ -159,9 +159,9 @@ int __init omap_mux_init_gpio(int gpio, int val)
 	return -ENODEV;
 }
 
-static int __init _omap_mux_get_by_name(struct omap_mux_partition *partition,
-					const char *muxname,
-					struct omap_mux **found_mux)
+static int _omap_mux_get_by_name(struct omap_mux_partition *partition,
+				 const char *muxname,
+				 struct omap_mux **found_mux)
 {
 	struct omap_mux *mux = NULL;
 	struct omap_mux_entry *e;

@@ -240,7 +240,7 @@ omap_mux_get_by_name(const char *muxname,
 	return -ENODEV;
 }
 
-int __init omap_mux_init_signal(const char *muxname, int val)
+int omap_mux_init_signal(const char *muxname, int val)
 {
 	struct omap_mux_partition *partition = NULL;
 	struct omap_mux *mux = NULL;

@@ -1094,8 +1094,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
 		omap_mux_package_init_balls(package_balls, superset);
 }
 
-static void omap_mux_init_signals(struct omap_mux_partition *partition,
-				  struct omap_board_mux *board_mux)
+static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
+					 struct omap_board_mux *board_mux)
 {
 	omap_mux_set_cmdline_signals();
 	omap_mux_write_array(partition, board_mux);

drivers/mfd/Kconfig +1 -1

@@ -200,7 +200,7 @@ config MENELAUS
 
 config TWL4030_CORE
 	bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support"
-	depends on I2C=y && GENERIC_HARDIRQS && IRQ_DOMAIN
+	depends on I2C=y && GENERIC_HARDIRQS
 	help
 	  Say yes here if you have TWL4030 / TWL6030 family chip on your board.
 	  This core driver provides register access and IRQ handling

drivers/mfd/twl-core.c +3 -0

@@ -263,7 +263,9 @@ struct twl_client {
 
 static struct twl_client twl_modules[TWL_NUM_SLAVES];
 
+#ifdef CONFIG_IRQ_DOMAIN
 static struct irq_domain domain;
+#endif
 
 /* mapping the module id to slave id and base address */
 struct twl_mapping {

@@ -1226,13 +1228,13 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
 	pdata->irq_base = status;
 	pdata->irq_end = pdata->irq_base + nr_irqs;
 
+#ifdef CONFIG_IRQ_DOMAIN
 	domain.irq_base = pdata->irq_base;

Quoted 5 lines · Russell King - ARM Linux

In any case, here's my current (tested) patch unbreaking OMAP as a whole, not only for all these section mismatches but the more fundamental issues like the broken serial ports on OMAP3 and the irq domain buggeration too.

This leaves one section mismatch for me in the OMAP hotplug code.

OK great all the section mismatch warning fixes look correct to me except one. The ones that make things __init should be a separate clean-up patch for the next merge window.

Quoted 26 lines

arch/arm/mach-omap2/hsmmc.c +3 -3

@@ -293,8 +293,8 @@ static inline void omap_hsmmc_mux(struct omap_mmc_platform_data *mmc_controller,
 	}
 }
 
-static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
-					struct omap_mmc_platform_data *mmc)
+static int omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
+				 struct omap_mmc_platform_data *mmc)
 {
 	char *hc_name;
 

@@ -430,7 +430,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
 
 #define MAX_OMAP_MMC_HWMOD_NAME_LEN		16
 
-void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
+void omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 {
 	struct omap_hwmod *oh;
 	struct platform_device *pdev;

@@ -487,7 +487,7 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
 	kfree(mmc_data);
 }
 

arch/arm/mach-omap2/hsmmc.c void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr) · line 493

Quoted 5 lines

arch/arm/mach-omap2/hsmmc.c +1 -1

-void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
+void omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
 {
 	u32 reg;
 

All these hsmmc_init functions should stay __init. There's something wrong in the calling function if that's not the case. Or else there's something wrong inside these functions that needs to be fixed.

Does making sdp3430_twl_gpio_setup() into __init fix those warnings for you? That should be safe as omap3430_i2c_init() is __init.

Quoted 59 lines

arch/arm/mach-omap2/mux.c +9 -9

@@ -100,8 +100,8 @@ void omap_mux_write_array(struct omap_mux_partition *partition,
 
 static char *omap_mux_options;
 
-static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
-				      int gpio, int val)
+static int _omap_mux_init_gpio(struct omap_mux_partition *partition,
+			       int gpio, int val)
 {
 	struct omap_mux_entry *e;
 	struct omap_mux *gpio_mux = NULL;

@@ -145,7 +145,7 @@ static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
 	return 0;
 }
 
-int __init omap_mux_init_gpio(int gpio, int val)
+int omap_mux_init_gpio(int gpio, int val)
 {
 	struct omap_mux_partition *partition;
 	int ret;

@@ -159,9 +159,9 @@ int __init omap_mux_init_gpio(int gpio, int val)
 	return -ENODEV;
 }
 
-static int __init _omap_mux_get_by_name(struct omap_mux_partition *partition,
-					const char *muxname,
-					struct omap_mux **found_mux)
+static int _omap_mux_get_by_name(struct omap_mux_partition *partition,
+				 const char *muxname,
+				 struct omap_mux **found_mux)
 {
 	struct omap_mux *mux = NULL;
 	struct omap_mux_entry *e;

@@ -240,7 +240,7 @@ omap_mux_get_by_name(const char *muxname,
 	return -ENODEV;
 }
 
-int __init omap_mux_init_signal(const char *muxname, int val)
+int omap_mux_init_signal(const char *muxname, int val)
 {
 	struct omap_mux_partition *partition = NULL;
 	struct omap_mux *mux = NULL;

@@ -1094,8 +1094,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
 		omap_mux_package_init_balls(package_balls, superset);
 }
 
-static void omap_mux_init_signals(struct omap_mux_partition *partition,
-				  struct omap_board_mux *board_mux)
+static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
+					 struct omap_board_mux *board_mux)
 {
 	omap_mux_set_cmdline_signals();
 	omap_mux_write_array(partition, board_mux);

@@ -1109,8 +1109,8 @@ static void omap_mux_init_package(struct omap_mux *superset,
 {
 }
 

arch/arm/mach-omap2/mux.c static void omap_mux_init_package(struct omap_mux *superset, · line 1116

Quoted 7 lines

arch/arm/mach-omap2/mux.c +2 -2

-static void omap_mux_init_signals(struct omap_mux_partition *partition,
-				  struct omap_board_mux *board_mux)
+static void __init omap_mux_init_signals(struct omap_mux_partition *partition,
+					 struct omap_board_mux *board_mux)
 {
 }
 

All the omap_mux_init_* functions should also __init. Again, there's something wrong with the calling function if the caller is not __init.

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 426

Quoted 12 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

This does not look right to me. I thought reverting of the serial patches should have already solved the issue you're seeing with slow serial port?

Those are the reverting commits drivers/tty/serial/serial-omap.c:

8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode")

af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip")

Quoted 10 lines · Tony Lindgren

Quoted 5 lines · Russell King - ARM Linux

In any case, here's my current (tested) patch unbreaking OMAP as a whole, not only for all these section mismatches but the more fundamental issues like the broken serial ports on OMAP3 and the irq domain buggeration too.

This leaves one section mismatch for me in the OMAP hotplug code.

OK great all the section mismatch warning fixes look correct to me except one. The ones that make things __init should be a separate clean-up patch for the next merge window.

Err. This stuff _really_ isn't merge window stuff. It's -rc stuff. Why?

If there's the possibility that stuff in the .init sections could be called after it has been discarded (which is basically what the section mismatch warnings are telling you) there is the potential for OOPSing the kernel.

They are _bug_ fixes.

So, we have a non-__init function calling an __init function which will be discarded at runtime and the memory associated with omap2_hsmmc_init() poisoned.

Now, the question is, can this function be called at runtime? Well, this is platform data for the TWL4030 GPIO platform device, and the TWL4030 GPIO platform driver is a loadable module:

config GPIO_TWL4030

        tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"

So, it can be built as a loadable module, and then loaded into the kernel _after_ the __init code has been discarded. When that happens on the 3430SDP, the .setup function will be called, and therefore the discarded omap2_hsmmc_init() will also be called.

Therefore omap2_hsmmc_init() and its called functions _must_ _not_ be marked __init - or 3430SDP needs to be fixed so that HSMMC is not dependent on TWL4030.

But, as long as the code is structured in this way, the HSMMC code _must_ lose its __init attributes.

What I suggest is that these changes get applied as is for -rc, fixing the OOPS potential of the current situation. Then, for the merge window, a proper solution to the 'omap2_hsmmc_init() might be called after init time' problem gets merged and then these functions can go back to being __init marked.

Quoted 2 lines

Does making sdp3430_twl_gpio_setup() into __init fix those warnings for you? That should be safe as omap3430_i2c_init() is __init.

See above why that's a very very wrong solution.

Quoted 2 lines

All the omap_mux_init_* functions should also __init. Again, there's something wrong with the calling function if the caller is not __init.

I disagree.

Unfortunately, you have code which is not __init only which calls them. As I've already proven above, for example, hsmmc stuff must not be marked __init given the current structure of OMAP code. Because hsmmc calls into the OMAP mux stuff (specifically omap_mux_init_signal()) it too can't be marked __init.

So, for now the __init stuff must go, until the bigger problem of why omap2_hsmmc_init() can get called from non-init contexts.

Quoted 16 lines

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 426

Quoted 11 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

This does not look right to me. I thought reverting of the serial patches should have already solved the issue you're seeing with slow serial port?

Quoted 7 lines

Those are the reverting commits drivers/tty/serial/serial-omap.c:

8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode")

af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip")

These commits have absolutely nothing to do with it. I pointed out the bad commit in one of my emails:

commit 2fd149645eb46d26130d7070c6de037dddf34880

Author: Govindraj.R <[email protected]>
Date:   Wed Nov 9 17:41:21 2011 +0530

ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos

Omap_uart_can_sleep function blocks system wide low power state until uart is active remove this func and add qos requests to prevent MPU from transitioning.

Keep qos request to default value which will allow MPU to transition and while uart baud rate is available calculate the latency value from the baudrate and use the same to hold constraint while uart clocks are enabled, and if uart is auto-idled the constraint is updated with default constraint value allowing MPU to transition.

Qos requests are blocking notifier calls so put these requests to work queue, also the driver uses irq_safe version of runtime API's and callbacks can be called in interrupt disabled context. So to avoid warn on slow path warning while using qos update API's from runtime callbacks use the qos_work_queue.

During bootup the runtime_resume call backs might not be called and runtime callback gets called only after uart is idled by setting the autosuspend timeout. So qos_request from runtime resume callback might not activated during boot if uart baudrate is calculated during bootup for console uart, so schedule the qos_work queue once we calc_latency while configuring the uart port.

Flush and complete any pending qos jobs in work queue while suspending.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty changes)

Signed-off-by Kevin Hilman <[email protected]>

Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs while in some of the deeper low power modes.

I tried reverting the rest of the patches between this one and HEAD for omap-serial.c, but they have no effect what so ever on this bug. As I said in one of my emails in this thread, the above commit can't be trivially reverted because some other stuff that the code relied upon has vanished.

So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c is the smallest 'fix' I could find of resolving the regression.

Quoted 70 lines

Quoted 16 lines

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 426

Quoted 11 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

This does not look right to me. I thought reverting of the serial patches should have already solved the issue you're seeing with slow serial port?

Quoted 7 lines

Those are the reverting commits drivers/tty/serial/serial-omap.c:

8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode")

af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip")

These commits have absolutely nothing to do with it. I pointed out the bad commit in one of my emails:

commit 2fd149645eb46d26130d7070c6de037dddf34880

Author: Govindraj.R <[email protected]>
Date:   Wed Nov 9 17:41:21 2011 +0530

ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos

Omap_uart_can_sleep function blocks system wide low power state until uart is active remove this func and add qos requests to prevent MPU from transitioning.

Keep qos request to default value which will allow MPU to transition and while uart baud rate is available calculate the latency value from the baudrate and use the same to hold constraint while uart clocks are enabled, and if uart is auto-idled the constraint is updated with default constraint value allowing MPU to transition.

Qos requests are blocking notifier calls so put these requests to work queue, also the driver uses irq_safe version of runtime API's and callbacks can be called in interrupt disabled context. So to avoid warn on slow path warning while using qos update API's from runtime callbacks use the qos_work_queue.

During bootup the runtime_resume call backs might not be called and runtime callback gets called only after uart is idled by setting the autosuspend timeout. So qos_request from runtime resume callback might not activated during boot if uart baudrate is calculated during bootup for console uart, so schedule the qos_work queue once we calc_latency while configuring the uart port.

Flush and complete any pending qos jobs in work queue while suspending.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty changes)

Signed-off-by Kevin Hilman <[email protected]>

Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs while in some of the deeper low power modes.

I tried reverting the rest of the patches between this one and HEAD for omap-serial.c, but they have no effect what so ever on this bug. As I said in one of my emails in this thread, the above commit can't be trivially reverted because some other stuff that the code relied upon has vanished.

Quoted 2 lines

So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c is the smallest 'fix' I could find if resolving the regression.

OK, thanks, that should be enough info for let Kevin take a look at this.

Tony Lindgren <[email protected]> writes:

[...]

Quoted 33 lines

Quoted 33 lines

Quoted 16 lines

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 426

Quoted 11 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

This does not look right to me. I thought reverting of the serial patches should have already solved the issue you're seeing with slow serial port?

Quoted 7 lines

Those are the reverting commits drivers/tty/serial/serial-omap.c:

8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode")

af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip")

These commits have absolutely nothing to do with it. I pointed out the bad commit in one of my emails:

commit 2fd149645eb46d26130d7070c6de037dddf34880

Author: Govindraj.R <[email protected]>
Date:   Wed Nov 9 17:41:21 2011 +0530

ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos

Quoted 13 lines

Quoted 12 lines

Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs while in some of the deeper low power modes.

I tried reverting the rest of the patches between this one and HEAD for omap-serial.c, but they have no effect what so ever on this bug. As I said in one of my emails in this thread, the above commit can't be trivially reverted because some other stuff that the code relied upon has vanished.

So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c is the smallest 'fix' I could find if resolving the regression.

Quoted 1 line

OK, thanks, that should be enough info for let Kevin take a look at this.

This one is indeed strange. I have not seen this on the 34xx devices I'm using (3430/n900, 3530/Overo, 3630/Zoom3).

Just to confirm. I assume you are using v3.3-rc2 (or later Linus master) which has a few fixes for this driver already.

Also, is this happening on your LDP. Which ES revision does your 3430 have?

Kevin

Quoted 2 lines · Víctor M. Jáquez L.

If it helps, I observed the same issue in a beagleboard rev B6, with v3.3-rc2

Great, thanks. Can you share your ~/.config?

Quoted 5 lines · Kevin Hilman

Quoted 2 lines · Víctor M. Jáquez L.

If it helps, I observed the same issue in a beagleboard rev B6, with v3.3-rc2

Great, thanks. Can you share your ~/.config?

If it helps, ARM Kautobuild V2 is up and running (assuming I don't break the scripts again) at:

http://www.arm.linux.org.uk/developer/build/

from where the build configs I use (and the exact ones used in those compiles) are available. These aren't configs in arch/arm/configs.

Quoted 7 lines · Russell King - ARM Linux

Quoted 5 lines · Kevin Hilman

Quoted 2 lines · Víctor M. Jáquez L.

If it helps, I observed the same issue in a beagleboard rev B6, with v3.3-rc2

Great, thanks. Can you share your ~/.config?

Quoted 7 lines

If it helps, ARM Kautobuild V2 is up and running (assuming I don't break the scripts again) at:

http://www.arm.linux.org.uk/developer/build/

from where the build configs I use (and the exact ones used in those compiles) are available. These aren't configs in arch/arm/configs.

Great. How do you generate the allnoconfig there?

I tried:

ARCH=arm make KCONFIG_ALLCONFIG=my_config allnoconfig

But it really does a total ARM noconfig that currently has no chance in building currently?

Quoted 16 lines · Tony Lindgren

Quoted 7 lines · Russell King - ARM Linux

Quoted 5 lines · Kevin Hilman

Quoted 2 lines · Víctor M. Jáquez L.

If it helps, I observed the same issue in a beagleboard rev B6, with v3.3-rc2

Great, thanks. Can you share your ~/.config?

Quoted 7 lines

If it helps, ARM Kautobuild V2 is up and running (assuming I don't break the scripts again) at:

http://www.arm.linux.org.uk/developer/build/

from where the build configs I use (and the exact ones used in those compiles) are available. These aren't configs in arch/arm/configs.

Quoted 8 lines

Great. How do you generate the allnoconfig there?

I tried:

ARCH=arm make KCONFIG_ALLCONFIG=my_config allnoconfig

But it really does a total ARM noconfig that currently has no chance in building currently?

Each of the builds have a seed configuration, even allnoconfig.

The seed configuration for the oldconfig's are a 'make savedefconfig' version of the build config I've been using.

For the allnoconfig, there's a minimal set of configuration symbols to set - mainly to set the target platform but with CONFIG_MMU=y.

So, for the LDP, it's:

CONFIG_MMU=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_ARCH_OMAP3=y
CONFIG_SOC_OMAP3430=y
CONFIG_MACH_OMAP_LDP=y

and 4430SDP:

CONFIG_MMU=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_ARCH_OMAP4=y
CONFIG_MACH_OMAP_4430SDP=y

Quoted 5 lines · Kevin Hilman

Quoted 2 lines · Víctor M. Jáquez L.

If it helps, I observed the same issue in a beagleboard rev B6, with v3.3-rc2

Great, thanks. Can you share your ~/.config?

If it helps, ARM Kautobuild V2 is up and running (assuming I don't break the scripts again) at:

http://www.arm.linux.org.uk/developer/build/

from where the build configs I use (and the exact ones used in those compiles) are available. These aren't configs in arch/arm/configs.

Tony Lindgren <[email protected]> writes:

[...]

Quoted 70 lines

Quoted 70 lines

Quoted 16 lines

arch/arm/mach-omap2/pm34xx.c static void omap3_pm_idle(void) · line 426

Quoted 11 lines

arch/arm/mach-omap2/pm34xx.c +1 -1

@@ -420,7 +420,7 @@ static void omap3_pm_idle(void)
 {
 	local_fiq_disable();
 
-	if (omap_irq_pending())
+	if (omap_irq_pending() || 1)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());

This does not look right to me. I thought reverting of the serial patches should have already solved the issue you're seeing with slow serial port?

Quoted 7 lines

Those are the reverting commits drivers/tty/serial/serial-omap.c:

8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode")

af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip")

These commits have absolutely nothing to do with it. I pointed out the bad commit in one of my emails:

commit 2fd149645eb46d26130d7070c6de037dddf34880

Author: Govindraj.R <[email protected]>
Date:   Wed Nov 9 17:41:21 2011 +0530

ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos

Omap_uart_can_sleep function blocks system wide low power state until uart is active remove this func and add qos requests to prevent MPU from transitioning.

Keep qos request to default value which will allow MPU to transition and while uart baud rate is available calculate the latency value from the baudrate and use the same to hold constraint while uart clocks are enabled, and if uart is auto-idled the constraint is updated with default constraint value allowing MPU to transition.

Qos requests are blocking notifier calls so put these requests to work queue, also the driver uses irq_safe version of runtime API's and callbacks can be called in interrupt disabled context. So to avoid warn on slow path warning while using qos update API's from runtime callbacks use the qos_work_queue.

During bootup the runtime_resume call backs might not be called and runtime callback gets called only after uart is idled by setting the autosuspend timeout. So qos_request from runtime resume callback might not activated during boot if uart baudrate is calculated during bootup for console uart, so schedule the qos_work queue once we calc_latency while configuring the uart port.

Flush and complete any pending qos jobs in work queue while suspending.

Signed-off-by Govindraj.R <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]> (for drivers/tty changes)

Signed-off-by Kevin Hilman <[email protected]>

Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs while in some of the deeper low power modes.

I tried reverting the rest of the patches between this one and HEAD for omap-serial.c, but they have no effect what so ever on this bug. As I said in one of my emails in this thread, the above commit can't be trivially reverted because some other stuff that the code relied upon has vanished.

Quoted 4 lines

Quoted 2 lines

So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c is the smallest 'fix' I could find if resolving the regression.

OK, thanks, that should be enough info for let Kevin take a look at this.

This one is indeed strange. I have not seen this on the 34xx devices I'm using (3430/n900, 3530/Overo, 3630/Zoom3).

Quoted 13 lines · Kevin Hilman

Tony Lindgren <[email protected]> writes:

[...]

Quoted 9 lines

Quoted 9 lines

Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs while in some of the deeper low power modes.

I tried reverting the rest of the patches between this one and HEAD for omap-serial.c, but they have no effect what so ever on this bug.  As I said in one of my emails in this thread, the above commit can't be trivially reverted because some other stuff that the code relied upon has vanished.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c is the smallest 'fix' I could find if resolving the regression.

OK, thanks, that should be enough info for let Kevin take a look at this.

This one is indeed strange.  I have not seen this on the 34xx devices I'm using (3430/n900, 3530/Overo, 3630/Zoom3).

OK, I've reproduced this on v3.3-rc2.

The reason I wasn't seeing this is because I'm using the fixes Paul has already posted that fix this problem:

       http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2

Kevin

Quoted 7 lines · Kevin Hilman

Quoted 2 lines · Kevin Hilman

This one is indeed strange.  I have not seen this on the 34xx devices I'm using (3430/n900, 3530/Overo, 3630/Zoom3).

OK, I've reproduced this on v3.3-rc2.

Quoted 6 lines

The reason I wasn't seeing this is because I'm using the fixes Paul has already posted that fix this problem:

       http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2

Kevin

But it looks like these are now queued for 3.4 in tty tree?

Quoted 13 lines · Grazvydas Ignotas

Quoted 12 lines · Kevin Hilman

Quoted 2 lines · Kevin Hilman

This one is indeed strange.  I have not seen this on the 34xx devices I'm using (3430/n900, 3530/Overo, 3630/Zoom3).

OK, I've reproduced this on v3.3-rc2.

The reason I wasn't seeing this is because I'm using the fixes Paul has already posted that fix this problem:

       http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2

Quoted 3 lines

Quoted 1 line

Kevin

But it looks like these are now queued for 3.4 in tty tree?

I believe they were targettted for 3.3-rc.

Paul, Greg, can you confirm?

Quoted 19 lines · Kevin Hilman

Quoted 16 lines · Grazvydas Ignotas

Quoted 5 lines · Kevin Hilman

Quoted 2 lines · Kevin Hilman

This one is indeed strange.  I have not seen this on the 34xx devices I'm using (3430/n900, 3530/Overo, 3630/Zoom3).

Quoted 8 lines

OK, I've reproduced this on v3.3-rc2.

The reason I wasn't seeing this is because I'm using the fixes Paul has already posted that fix this problem:

       http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2

Kevin

But it looks like these are now queued for 3.4 in tty tree?

Quoted 3 lines

I believe they were targettted for 3.3-rc.

Paul, Greg, can you confirm?

I have no idea what you are refering to here, please be much more specific.  You can look at the linux-next tree to answer your question yourself as well...

Quoted 20 lines · Greg KH

Quoted 19 lines · Kevin Hilman

Quoted 16 lines · Grazvydas Ignotas

Quoted 5 lines · Kevin Hilman

Quoted 2 lines · Kevin Hilman

This one is indeed strange.  I have not seen this on the 34xx devices I'm using (3430/n900, 3530/Overo, 3630/Zoom3).

Quoted 8 lines

OK, I've reproduced this on v3.3-rc2.

The reason I wasn't seeing this is because I'm using the fixes Paul has already posted that fix this problem:

       http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2

Kevin

But it looks like these are now queued for 3.4 in tty tree?

Quoted 7 lines

Quoted 3 lines

I believe they were targettted for 3.3-rc.

Paul, Greg, can you confirm?

I have no idea what you are refering to here, please be much more specific.  You can look at the linux-next tree to answer your question yourself as well...

It's about these patches in gregkh/tty.git tty-next:
6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
edbe5db tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

It would look to me like they are queued for 3.4 but Kevin says there were intended for 3.3-rc.

Quoted 2 lines

It would look to me like they are queued for 3.4 but Kevin says there were intended for 3.3-rc.

Kevin might have wished they would go into 3.3, but given that the first round of these patches had to be reverted, I thought it safer to wait for 3.4.

Hi Greg,

Greg KH <[email protected]> writes:

[...]

Quoted 3 lines

Quoted 2 lines

It would look to me like they are queued for 3.4 but Kevin says there were intended for 3.3-rc.

Quoted 3 lines

Kevin might have wished they would go into 3.3, but given that the first round of these patches had to be reverted, I thought it safer to wait for 3.4.

Sorry for the churn on these, but I guess we weren't expecting you to apply the first before it got some testing/acks. Sorry about that.

The version you have currently queued is needed for v3.3 as they fix brokenness on v3.3. Any chance they can be applied queued for 3.3? We'll have another set of enhancements on top of those that are targetted for v3.4, but those you have queued currently are defintely fixes.

Don't send me anything, saying it needs to get into the -rc merge window, that you don't actually want to see merged. Otherwise, how long am I supposed to know to wait? That's just looney.

Quoted 5 lines

The version you have currently queued is needed for v3.3 as they fix brokenness on v3.3. Any chance they can be applied queued for 3.3? We'll have another set of enhancements on top of those that are targetted for v3.4, but those you have queued currently are defintely fixes.

At this point in the release cycle, I would prefer to wait.

Hi Greg

was just directed at this thread:

Quoted 3 lines · Greg KH

Don't send me anything, saying it needs to get into the -rc merge window, that you don't actually want to see merged. Otherwise, how long am I supposed to know to wait? That's just looney.

We did want to see it merged. But then we came up with a better fix, which is why I asked you to revert the original in favor of the new version:

http://marc.info/?l=linux-arm-kernel&m=132760582332651&w=2

If we'd realized that the second version would be delayed until 3.4, we wouldn't have wanted the first version to be reverted :-(

Quoted 6 lines

Quoted 5 lines

The version you have currently queued is needed for v3.3 as they fix brokenness on v3.3. Any chance they can be applied queued for 3.3? We'll have another set of enhancements on top of those that are targetted for v3.4, but those you have queued currently are defintely fixes.

Quoted 1 line

At this point in the release cycle, I would prefer to wait.

It would be really great if this series could make it in for v3.3-rcX. Without it, 3.3 will be unusable for any OMAP users that run the console on the serial port. That's pretty much every OMAP user that runs mainline kernels, AFAIK.

What changeset(s) do you want me to take from my tty-next tree and put it in the tty-linus tree to be merged for the 3.3-final timeframe?

Quoted 2 lines · Greg KH

What changeset(s) do you want me to take from my tty-next tree and put it in the tty-linus tree to be merged for the 3.3-final timeframe?

6bbcbf2 tty: serial: omap-serial: wakeup latency constraint is in microseconds, edbe5db tty: serial: OMAP: block idle while the UART is transferring data in PIO 5816269 tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

Quoted 10 lines · Paul Walmsley

Hi Greg

was just directed at this thread:

Quoted 3 lines · Greg KH

Don't send me anything, saying it needs to get into the -rc merge window, that you don't actually want to see merged. Otherwise, how long am I supposed to know to wait? That's just looney.

Quoted 8 lines

We did want to see it merged. But then we came up with a better fix, which is why I asked you to revert the original in favor of the new version:

http://marc.info/?l=linux-arm-kernel&m=132760582332651&w=2

If we'd realized that the second version would be delayed until 3.4, we wouldn't have wanted the first version to be reverted :-(

You said the first version was broken.

Anyway, moving on...

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

The version you have currently queued is needed for v3.3 as they fix brokenness on v3.3. Any chance they can be applied queued for 3.3? We'll have another set of enhancements on top of those that are targetted for v3.4, but those you have queued currently are defintely fixes.

Quoted 6 lines

Quoted 1 line

At this point in the release cycle, I would prefer to wait.

It would be really great if this series could make it in for v3.3-rcX. Without it, 3.3 will be unusable for any OMAP users that run the console on the serial port. That's pretty much every OMAP user that runs mainline kernels, AFAIK.

Show me an OMAP user that actually runs a mainline kernel :)

What changeset(s) do you want me to take from my tty-next tree and put it in the tty-linus tree to be merged for the 3.3-final timeframe?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Show me an OMAP user that actually runs a mainline kernel :)

Quoted 1 line · Greg KH

Show me an OMAP user that actually runs a mainline kernel :)

I guess pretty much all these days? Most error reports what I recall seeing during past 2-3 years are from mainline kernel and not that much from linux-omap or some board support package kernel.

Quoted 6 lines · Jarkko Nikula

Quoted 1 line · Greg KH

Show me an OMAP user that actually runs a mainline kernel :)

I guess pretty much all these days? Most error reports what I recall seeing during past 2-3 years are from mainline kernel and not that much from linux-omap or some board support package kernel.

Most of the other guys are going in via the TI support channels rather than asking on the public lists I expect (and remember that even if people are basing their code on mainline the chances are they've still got a bunch of out of tree changes on top for their own boards if they're not directly using one of the reference boards).

This fixes the various build and boot issues with custom .configs that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial console issues. And it fixes booting with DT to minimal enviroment.

Quoted 4 lines · Tony Lindgren

This fixes the various build and boot issues with custom .configs that don't select CONFIG_MACH_OMAP_GENERIC. It should fix slow serial console issues. And it fixes booting with DT to minimal enviroment.

Looks like the serial console is still insanely slow on 2420 both for dmesg.

On 2430, 3430, 3630 and 4430 it seems the problem with slow console is now fixed.

So at least one more patch is needed for the 2420 PM/serial regression.

From 98796ac6423302fdb56afa8a0a262fb09e27a1f6 Mon Sep 17 00:00:00 2001

Yeah, that one is PM related. If mach-omap2/pm24xx.c is hacked to only enter MPU retention, rather than full chip retention, it works (quick hack below). I suspect it is due to the lack of wakeup support in OMAP2 PM, but of course it could be something else.

Please everybody using omaps with mainline give a test for the merge of the various fixes planned. I've done a branch with v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes that I've queued up.

If you still see problems with compiling, booting, or slow serial port, please post the issues to linux-omap and LAKML lists immediately.

Thus spake Tony Lindgren ([email protected]):

Quoted 8 lines

Please everybody using omaps with mainline give a test for the merge of the various fixes planned. I've done a branch with v3.3-rc3 + Russell's fixes + Paul's serial port fixes + fixes that I've queued up.

If you still see problems with compiling, booting, or slow serial port, please post the issues to linux-omap and LAKML lists immediately.

With the testing branch, my serial port is still very slow.
The console is set to 115200, dmesg takes almost a minute to print out. I'm testing on a beagleboard-xm, which has the DM3730.
(if I change omap2_pm_idle() to never call omap_sram_idle() things improve *a lot*).

config: http://tonya.fnordsoft.com/omap-testing/config
dmesg: http://tonya.fnordsoft.com/omap-testing/testing-dmesg

Can you double check that you're building and booting using Tony's -rc3 based branch?

Also, can you do a test using omap2plus_defconfig?

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines · Paul Walmsley

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

I tried it on AM37x EVM, it did worked for me but I have some observations,

Hi

Quoted 2 lines · Vaibhav

Quoted 1 line · Paul Walmsley

Quoted 5 lines

Quoted 3 lines

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

I tried it on AM37x EVM, it did worked for me but I have some observations,

What .config are you using? omap2plus_defconfig?

- Paul

Quoted 4 lines · Paul Walmsley

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

I tried it on AM37x EVM, it did worked for me but I have some observations,

2) Missing clockdomain in usb clock -

[root@arago /]# dmesg | grep -ir hwmod

[    0.114868] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck.

...

3) Not sure how this can be handled, since from TWL regulator output perspective it is NA. I enabled DUMMY_REGILATOR option and tried it, it works.

[root@arago /]# dmesg | grep -ir fail

[    0.166717] dpll3_m2_clk rate change failed: -22
[    0.828521] sharp_ls_panel display0: failed to set lcd brightness
[    1.672454] smsc911x smsc911x.0: Failed to get supply 'vdd33a': -19

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

Quoted 3 lines · Paul Walmsley

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

Regarding the issue that Vaibhav reported with:

"omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck"

I also see it on my xM Rev. B. I went back and doublechecked 3.2.5 and this does not occur there. Enabled EHCI+SMSC95xx support on top of omap2plus_defconfig and that works fine for nfsroot in 3.2.5.

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

Quoted 3 lines

Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works.

Rex, care to confirm this is also the case for you with your custom .config?

I also get these warnings when compiling:

CC arch/arm/mach-omap2/usb-host.o
arch/arm/mach-omap2/usb-host.c: In function 'usbhs_init':
arch/arm/mach-omap2/usb-host.c:528: warning: assignment from incompatible pointer type