OMAP CRAP: The Continuing Story Of Brokenness

OMAP CRAP: The Continuing Story Of Brokenness

[Russell King - ARM Linux]

Yet again I find that I'm having to email about crap on OMAP3.

I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the way there's fatal build errors at EVERY merge
window.  The OMAP workflow is totally broken.  Something MUST change
in the way the OMAP community works to stop the continual breakage
at every single bloody merge window.

One is new:

WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
usb_musb_init: could not find omap_hwmod for usb_otg_hs
Modules linked in:
Backtrace:
[<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:0000008d
[<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
[<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
 r8:00000000 r7:00000013 r6:c0374b05 r5:c03f06e4 r4:c0374190
[<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c03ceb54>] (usb_musb_init+0xc0/0x174)
 r3:c02df894 r2:c03707d9
[<c03cea94>] (usb_musb_init+0x0/0x174) from [<c03ce02c>] (omap_ldp_init+0xb0/0x100)
 r6:c003e7d8 r5:c03f06e4 r4:c04053e4
[<c03cdf7c>] (omap_ldp_init+0x0/0x100) from [<c03c6788>] (customize_machine+0x24/0x30)
 r4:c03f03a8
[<c03c6764>] (customize_machine+0x0/0x30) from [<c0008710>] (do_one_initcall+0x9c/0x164)
[<c0008674>] (do_one_initcall+0x0/0x164) from [<c03c3284>] (kernel_init+0x7c/0x120)
[<c03c3208>] (kernel_init+0x0/0x120) from [<c003e7d8>] (do_exit+0x0/0x62c)
 r5:c03c3208 r4:00000000
---[ end trace 1b75b31a2719ed1c ]---
 omap_timer.1: alias fck already exists
 omap_timer.2: alias fck already exists
 omap_timer.3: alias fck already exists
 omap_timer.4: alias fck already exists
 omap_timer.5: alias fck already exists
 omap_timer.6: alias fck already exists
 omap_timer.7: alias fck already exists
 omap_timer.8: alias fck already exists
 omap_timer.9: alias fck already exists
 omap_timer.10: alias fck already exists
 omap_timer.11: alias fck already exists
 omap_timer.12: alias fck already exists
 omap-mcbsp.2: alias fck already exists
 omap-mcbsp.3: alias fck already exists

And this, which I reported on August 26th - so it's now over three months
old is still there.  Clearly, no one cares about this driver so shall I
delete the omap-hsmmc driver, or is someone going to clean up their crap?
Or shall we revert all those patches for adding the asynchronous mapping
of MMC requests until the _REGRESSION_ is fixed properly?

mmcblk0: error -84 transferring data, sector 149209, nr 56, cmd response 0x900,
card status 0xb00
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:865 check_unmap+0x1b0/0x76c()
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000080000000] [size=16384 bytes]
Modules linked in:
Backtrace:
[<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c1af7cb0 r6:c018bfc8 r5:c038b4ff r4:00000361
[<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
[<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
 r8:c1af7d48 r7:00000000 r6:00004000 r5:00000000 r4:80000000
[<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c018bfc8>] (check_unmap+0x1b0/0x76c)
 r3:c0375450 r2:c038b8f7
[<c018be18>] (check_unmap+0x0/0x76c) from [<c018c6fc>] (debug_dma_unmap_sg+0x100/0x134)
[<c018c5fc>] (debug_dma_unmap_sg+0x0/0x134) from [<c0019848>] (dma_unmap_sg+0x24/0x7c)
[<c0019824>] (dma_unmap_sg+0x0/0x7c) from [<c021112c>] (omap_hsmmc_post_req+0x48/0x54)
[<c02110e4>] (omap_hsmmc_post_req+0x0/0x54) from [<c0204a8c>] (mmc_start_req+0x9c/0x128)
 r4:c1ab2000
[<c02049f0>] (mmc_start_req+0x0/0x128) from [<c020e6a4>] (mmc_blk_issue_rw_rq+0x80/0x4e8)
 r8:c1aefc00 r7:c1aed800 r6:c1aefc24 r5:c1aed800 r4:c1aefc24
[<c020e624>] (mmc_blk_issue_rw_rq+0x0/0x4e8) from [<c020ef04>] (mmc_blk_issue_rq+0x3f8/0x428)
[<c020eb0c>] (mmc_blk_issue_rq+0x0/0x428) from [<c020fa8c>] (mmc_queue_thread+0xa0/0x104)
[<c020f9ec>] (mmc_queue_thread+0x0/0x104) from [<c0055bf0>] (kthread+0x88/0x90)
[<c0055b68>] (kthread+0x0/0x90) from [<c003e7d8>] (do_exit+0x0/0x62c)
 r7:00000013 r6:c003e7d8 r5:c0055b68 r4:c1831c5c
---[ end trace 1b75b31a2719ed1e ]---

OMAP CRAP: The Continuing Story Of Brokenness

[S, Venkatraman]

On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Yet again I find that I'm having to email about crap on OMAP3.
>
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window. ?The OMAP workflow is totally broken. ?Something MUST change
> in the way the OMAP community works to stop the continual breakage
> at every single bloody merge window.
>
> One is new:
>
> WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
> usb_musb_init: could not find omap_hwmod for usb_otg_hs
> Modules linked in:
> Backtrace:
> [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:0000008d
> [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
> [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
> ?r8:00000000 r7:00000013 r6:c0374b05 r5:c03f06e4 r4:c0374190
> [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c03ceb54>] (usb_musb_init+0xc0/0x174)
> ?r3:c02df894 r2:c03707d9
> [<c03cea94>] (usb_musb_init+0x0/0x174) from [<c03ce02c>] (omap_ldp_init+0xb0/0x100)
> ?r6:c003e7d8 r5:c03f06e4 r4:c04053e4
> [<c03cdf7c>] (omap_ldp_init+0x0/0x100) from [<c03c6788>] (customize_machine+0x24/0x30)
> ?r4:c03f03a8
> [<c03c6764>] (customize_machine+0x0/0x30) from [<c0008710>] (do_one_initcall+0x9c/0x164)
> [<c0008674>] (do_one_initcall+0x0/0x164) from [<c03c3284>] (kernel_init+0x7c/0x120)
> [<c03c3208>] (kernel_init+0x0/0x120) from [<c003e7d8>] (do_exit+0x0/0x62c)
> ?r5:c03c3208 r4:00000000
> ---[ end trace 1b75b31a2719ed1c ]---
> ?omap_timer.1: alias fck already exists
> ?omap_timer.2: alias fck already exists
> ?omap_timer.3: alias fck already exists
> ?omap_timer.4: alias fck already exists
> ?omap_timer.5: alias fck already exists
> ?omap_timer.6: alias fck already exists
> ?omap_timer.7: alias fck already exists
> ?omap_timer.8: alias fck already exists
> ?omap_timer.9: alias fck already exists
> ?omap_timer.10: alias fck already exists
> ?omap_timer.11: alias fck already exists
> ?omap_timer.12: alias fck already exists
> ?omap-mcbsp.2: alias fck already exists
> ?omap-mcbsp.3: alias fck already exists
>
> And this, which I reported on August 26th - so it's now over three months
> old is still there. ?Clearly, no one cares about this driver so shall I
> delete the omap-hsmmc driver, or is someone going to clean up their crap?
> Or shall we revert all those patches for adding the asynchronous mapping
> of MMC requests until the _REGRESSION_ is fixed properly?
>
Russell,
  I do apologize. I had posted a patch and didn't follow up on getting
it merged.
I will post a revised patch now.

> mmcblk0: error -84 transferring data, sector 149209, nr 56, cmd response 0x900,
> card status 0xb00
> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:865 check_unmap+0x1b0/0x76c()
> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000080000000] [size=16384 bytes]
> Modules linked in:
> Backtrace:
> [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c1af7cb0 r6:c018bfc8 r5:c038b4ff r4:00000361
> [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
> [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
> ?r8:c1af7d48 r7:00000000 r6:00004000 r5:00000000 r4:80000000
> [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c018bfc8>] (check_unmap+0x1b0/0x76c)
> ?r3:c0375450 r2:c038b8f7
> [<c018be18>] (check_unmap+0x0/0x76c) from [<c018c6fc>] (debug_dma_unmap_sg+0x100/0x134)
> [<c018c5fc>] (debug_dma_unmap_sg+0x0/0x134) from [<c0019848>] (dma_unmap_sg+0x24/0x7c)
> [<c0019824>] (dma_unmap_sg+0x0/0x7c) from [<c021112c>] (omap_hsmmc_post_req+0x48/0x54)
> [<c02110e4>] (omap_hsmmc_post_req+0x0/0x54) from [<c0204a8c>] (mmc_start_req+0x9c/0x128)
> ?r4:c1ab2000
> [<c02049f0>] (mmc_start_req+0x0/0x128) from [<c020e6a4>] (mmc_blk_issue_rw_rq+0x80/0x4e8)
> ?r8:c1aefc00 r7:c1aed800 r6:c1aefc24 r5:c1aed800 r4:c1aefc24
> [<c020e624>] (mmc_blk_issue_rw_rq+0x0/0x4e8) from [<c020ef04>] (mmc_blk_issue_rq+0x3f8/0x428)
> [<c020eb0c>] (mmc_blk_issue_rq+0x0/0x428) from [<c020fa8c>] (mmc_queue_thread+0xa0/0x104)
> [<c020f9ec>] (mmc_queue_thread+0x0/0x104) from [<c0055bf0>] (kthread+0x88/0x90)
> [<c0055b68>] (kthread+0x0/0x90) from [<c003e7d8>] (do_exit+0x0/0x62c)
> ?r7:00000013 r6:c003e7d8 r5:c0055b68 r4:c1831c5c
> ---[ end trace 1b75b31a2719ed1e ]---
>

OMAP CRAP: The Continuing Story Of Brokenness

[Per Förlin]

On 11/06/2011 01:18 PM, Russell King - ARM Linux wrote:
> Yet again I find that I'm having to email about crap on OMAP3.
> 
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window.  The OMAP workflow is totally broken.  Something MUST change
> in the way the OMAP community works to stop the continual breakage
> at every single bloody merge window.
> 
> One is new:
> 
> WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
> usb_musb_init: could not find omap_hwmod for usb_otg_hs
> Modules linked in:
> Backtrace:
> [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:0000008d
> [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
> [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
>  r8:00000000 r7:00000013 r6:c0374b05 r5:c03f06e4 r4:c0374190
> [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c03ceb54>] (usb_musb_init+0xc0/0x174)
>  r3:c02df894 r2:c03707d9
> [<c03cea94>] (usb_musb_init+0x0/0x174) from [<c03ce02c>] (omap_ldp_init+0xb0/0x100)
>  r6:c003e7d8 r5:c03f06e4 r4:c04053e4
> [<c03cdf7c>] (omap_ldp_init+0x0/0x100) from [<c03c6788>] (customize_machine+0x24/0x30)
>  r4:c03f03a8
> [<c03c6764>] (customize_machine+0x0/0x30) from [<c0008710>] (do_one_initcall+0x9c/0x164)
> [<c0008674>] (do_one_initcall+0x0/0x164) from [<c03c3284>] (kernel_init+0x7c/0x120)
> [<c03c3208>] (kernel_init+0x0/0x120) from [<c003e7d8>] (do_exit+0x0/0x62c)
>  r5:c03c3208 r4:00000000
> ---[ end trace 1b75b31a2719ed1c ]---
>  omap_timer.1: alias fck already exists
>  omap_timer.2: alias fck already exists
>  omap_timer.3: alias fck already exists
>  omap_timer.4: alias fck already exists
>  omap_timer.5: alias fck already exists
>  omap_timer.6: alias fck already exists
>  omap_timer.7: alias fck already exists
>  omap_timer.8: alias fck already exists
>  omap_timer.9: alias fck already exists
>  omap_timer.10: alias fck already exists
>  omap_timer.11: alias fck already exists
>  omap_timer.12: alias fck already exists
>  omap-mcbsp.2: alias fck already exists
>  omap-mcbsp.3: alias fck already exists
> 
> And this, which I reported on August 26th - so it's now over three months
> old is still there.  Clearly, no one cares about this driver so shall I
> delete the omap-hsmmc driver, or is someone going to clean up their crap?
> Or shall we revert all those patches for adding the asynchronous mapping
> of MMC requests until the _REGRESSION_ is fixed properly?
It's possible to disable async mapping in omap_hsmmc.c. Set pre_req and post_req to NULL.

Regards,
Per

OMAP CRAP: The Continuing Story Of Brokenness

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [111106 03:44]:
> Yet again I find that I'm having to email about crap on OMAP3.
> 
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window.  The OMAP workflow is totally broken.  Something MUST change
> in the way the OMAP community works to stop the continual breakage
> at every single bloody merge window.

Hmm he following fixes are queued elsewhere and now merged:

omap_hsmmc: fix missing parenthesis in pr_info
PM / OPP: Fix build when CONFIG_PM_OPP is not set 
net: Add back alignment for size for __alloc_skb

Or have you seen some other build errors?

FYI, now all the compile warnings are finally gone with what
I have in fixes branch.
 
> One is new:
> 
> WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
> usb_musb_init: could not find omap_hwmod for usb_otg_hs
> Modules linked in:
> Backtrace:
> [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:0000008d
> [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
> [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
>  r8:00000000 r7:00000013 r6:c0374b05 r5:c03f06e4 r4:c0374190
> [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c03ceb54>] (usb_musb_init+0xc0/0x174)
>  r3:c02df894 r2:c03707d9
> [<c03cea94>] (usb_musb_init+0x0/0x174) from [<c03ce02c>] (omap_ldp_init+0xb0/0x100)
>  r6:c003e7d8 r5:c03f06e4 r4:c04053e4
> [<c03cdf7c>] (omap_ldp_init+0x0/0x100) from [<c03c6788>] (customize_machine+0x24/0x30)
>  r4:c03f03a8
> [<c03c6764>] (customize_machine+0x0/0x30) from [<c0008710>] (do_one_initcall+0x9c/0x164)
> [<c0008674>] (do_one_initcall+0x0/0x164) from [<c03c3284>] (kernel_init+0x7c/0x120)
> [<c03c3208>] (kernel_init+0x0/0x120) from [<c003e7d8>] (do_exit+0x0/0x62c)
>  r5:c03c3208 r4:00000000

Felipe, care to check what the status of the musb hwmod issue
above is?


> ---[ end trace 1b75b31a2719ed1c ]---
>  omap_timer.1: alias fck already exists
>  omap_timer.2: alias fck already exists
>  omap_timer.3: alias fck already exists
>  omap_timer.4: alias fck already exists
>  omap_timer.5: alias fck already exists
>  omap_timer.6: alias fck already exists
>  omap_timer.7: alias fck already exists
>  omap_timer.8: alias fck already exists
>  omap_timer.9: alias fck already exists
>  omap_timer.10: alias fck already exists
>  omap_timer.11: alias fck already exists
>  omap_timer.12: alias fck already exists
>  omap-mcbsp.2: alias fck already exists
>  omap-mcbsp.3: alias fck already exists

The fix for this is queued as:

ARM: OMAP2+: clock data: Remove redundant timer clkdev

Regards,

Tony

OMAP CRAP: The Continuing Story Of Brokenness

[Russell King - ARM Linux]

On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [111106 03:44]:
> > Yet again I find that I'm having to email about crap on OMAP3.
> > 
> > I'm getting really fed up with OMAP stuff which keeps breaking in
> > idiotic ways - and the way there's fatal build errors at EVERY merge
> > window.  The OMAP workflow is totally broken.  Something MUST change
> > in the way the OMAP community works to stop the continual breakage
> > at every single bloody merge window.
> 
> Hmm he following fixes are queued elsewhere and now merged:
> 
> omap_hsmmc: fix missing parenthesis in pr_info
> PM / OPP: Fix build when CONFIG_PM_OPP is not set 
> net: Add back alignment for size for __alloc_skb
> 
> Or have you seen some other build errors?
> 
> FYI, now all the compile warnings are finally gone with what
> I have in fixes branch.

It was the errors in the "ARM: OMAP: Fix build for OMAP3 only builds"
thread.

However, rebuilding today gives brand new breakage - for my OMAP4430SDP
config.  This seems to be because more linux/module.h includes have been
deleted from include/linux/*.h includes.

arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:184: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:184: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:215: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:215: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:215: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:228: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:228: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:228: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:234: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:234: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:234: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:240: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:240: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:240: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:248: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:248: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:248: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:294: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:294: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:294: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:302: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:302: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:302: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:316: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:316: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:316: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:344: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:344: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:344: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:361: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:361: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:361: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:380: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:380: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:380: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:406: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:406: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:406: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:443: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:443: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:443: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:468: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:468: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:468: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:494: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:494: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:494: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:517: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:517: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:517: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:534: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:534: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:534: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:549: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:549: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:549: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:561: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:561: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:561: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:572: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:572: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:572: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:587: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:587: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:587: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:604: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:604: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/arm/plat-omap/dmtimer.c:604: warning: parameter names (without types) in function declaration
arch/arm/plat-omap/dmtimer.c:746: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:746: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:746: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
arch/arm/plat-omap/dmtimer.c:746: warning: function declaration isn't a prototype
arch/arm/plat-omap/dmtimer.c:747: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:747: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:747: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
arch/arm/plat-omap/dmtimer.c:747: warning: function declaration isn't a prototype
arch/arm/plat-omap/dmtimer.c:748: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:748: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:748: warning: type defaults to 'int' in declaration of 'MODULE_ALIAS'
arch/arm/plat-omap/dmtimer.c:748: warning: function declaration isn't a prototype
arch/arm/plat-omap/dmtimer.c:749: error: expected declaration specifiers or '...' before string constant
arch/arm/plat-omap/dmtimer.c:749: warning: data definition has no type or storage class
arch/arm/plat-omap/dmtimer.c:749: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
arch/arm/plat-omap/dmtimer.c:749: warning: function declaration isn't a prototype
arch/arm/mach-omap2/omap_l3_noc.c:250: error: 'THIS_MODULE' undeclared here (not in a function)
arch/arm/mach-omap2/usb-musb.c:64: warning: 'usb_musb_mux_init' defined but not used

In addition, for OMAP3430 LDP:

arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class
arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration
arch/arm/mach-omap2/mailbox.c:417: error: expected declaration specifiers or '...' before string constant
arch/arm/mach-omap2/mailbox.c:417: warning: data definition has no type or storage class
arch/arm/mach-omap2/mailbox.c:417: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
arch/arm/mach-omap2/mailbox.c:417: warning: function declaration isn't a prototype
arch/arm/mach-omap2/mailbox.c:418: error: expected declaration specifiers or '...' before string constant
arch/arm/mach-omap2/mailbox.c:418: warning: data definition has no type or storage class
arch/arm/mach-omap2/mailbox.c:418: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
arch/arm/mach-omap2/mailbox.c:418: warning: function declaration isn't a prototype
arch/arm/mach-omap2/mailbox.c:419: error: expected declaration specifiers or '...' before string constant
arch/arm/mach-omap2/mailbox.c:419: warning: data definition has no type or storage class
arch/arm/mach-omap2/mailbox.c:419: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
arch/arm/mach-omap2/mailbox.c:419: warning: function declaration isn't a prototype
arch/arm/mach-omap2/mailbox.c:420: error: expected declaration specifiers or '...' before string constant
arch/arm/mach-omap2/mailbox.c:420: warning: data definition has no type or storage class
arch/arm/mach-omap2/mailbox.c:420: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
arch/arm/mach-omap2/mailbox.c:420: warning: function declaration isn't a prototype
arch/arm/mach-omap2/mailbox.c:421: error: expected declaration specifiers or '...' before string constant
arch/arm/mach-omap2/mailbox.c:421: warning: data definition has no type or storage class
arch/arm/mach-omap2/mailbox.c:421: warning: type defaults to 'int' in declaration of 'MODULE_ALIAS'
arch/arm/mach-omap2/mailbox.c:421: warning: function declaration isn't a prototype
drivers/video/omap/dispc.c:276: warning: data definition has no type or storage class
drivers/video/omap/dispc.c:276: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
drivers/video/omap/dispc.c:276: warning: parameter names (without types) in function declaration
drivers/video/omap/dispc.c:286: warning: data definition has no type or storage class
drivers/video/omap/dispc.c:286: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
drivers/video/omap/dispc.c:286: warning: parameter names (without types) in function declaration
drivers/video/omap/dispc.c:320: warning: data definition has no type or storage class
drivers/video/omap/dispc.c:320: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
drivers/video/omap/dispc.c:320: warning: parameter names (without types) in function declaration
drivers/video/omap/dispc.c:328: warning: data definition has no type or storage class
drivers/video/omap/dispc.c:328: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
drivers/video/omap/dispc.c:328: warning: parameter names (without types) in function declaration
drivers/video/omap/dispc.c:863: warning: data definition has no type or storage class
drivers/video/omap/dispc.c:863: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
drivers/video/omap/dispc.c:863: warning: parameter names (without types) in function declaration
drivers/video/omap/dispc.c:883: warning: data definition has no type or storage class
drivers/video/omap/dispc.c:883: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
drivers/video/omap/dispc.c:883: warning: parameter names (without types) in function declaration

It might be an idea to do this:

grep -rl EXPORT_SYMBOL arch/arm/*omap* | xargs grep -L linux/export.h

and for any OMAP drivers as well.  This gives:

arch/arm/mach-omap1/id.c
arch/arm/mach-omap1/lcd_dma.c
arch/arm/mach-omap1/io.c
arch/arm/mach-omap1/ams-delta-fiq.c
arch/arm/mach-omap2/gpmc.c
arch/arm/mach-omap2/id.c
arch/arm/mach-omap2/io.c
arch/arm/plat-omap/ocpi.c
arch/arm/plat-omap/mcbsp.c
arch/arm/plat-omap/omap_device.c
arch/arm/plat-omap/mux.c
arch/arm/plat-omap/devices.c
arch/arm/plat-omap/io.c
arch/arm/plat-omap/dma.c
arch/arm/plat-omap/dmtimer.c
arch/arm/plat-omap/mailbox.c

which probably should all be fixed before any more of these errors
spring up.

OMAP CRAP: The Continuing Story Of Brokenness

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [111107 09:12]:
> On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [111106 03:44]:
> > > Yet again I find that I'm having to email about crap on OMAP3.
> > > 
> > > I'm getting really fed up with OMAP stuff which keeps breaking in
> > > idiotic ways - and the way there's fatal build errors at EVERY merge
> > > window.  The OMAP workflow is totally broken.  Something MUST change
> > > in the way the OMAP community works to stop the continual breakage
> > > at every single bloody merge window.
> > 
> > Hmm he following fixes are queued elsewhere and now merged:
> > 
> > omap_hsmmc: fix missing parenthesis in pr_info
> > PM / OPP: Fix build when CONFIG_PM_OPP is not set 
> > net: Add back alignment for size for __alloc_skb
> > 
> > Or have you seen some other build errors?
> > 
> > FYI, now all the compile warnings are finally gone with what
> > I have in fixes branch.
> 
> It was the errors in the "ARM: OMAP: Fix build for OMAP3 only builds"
> thread.

OK, that's queued up.
 
> However, rebuilding today gives brand new breakage - for my OMAP4430SDP
> config.  This seems to be because more linux/module.h includes have been
> deleted from include/linux/*.h includes.
> 
> arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or storage class
...

Got a fix for that one queued up too.

 
> In addition, for OMAP3430 LDP:
> 
> arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class
> arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration

Looks like there's a fix for this one posted, will add that.

> arch/arm/mach-omap2/mailbox.c:417: error: expected declaration specifiers or '...' before string constant
> arch/arm/mach-omap2/mailbox.c:417: warning: data definition has no type or storage class
> arch/arm/mach-omap2/mailbox.c:417: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
...

> drivers/video/omap/dispc.c:276: warning: data definition has no type or storage class
> drivers/video/omap/dispc.c:276: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'

Yeah after pulling in the current mainline I see at least the above
two need to be patched.

 
> It might be an idea to do this:
> 
> grep -rl EXPORT_SYMBOL arch/arm/*omap* | xargs grep -L linux/export.h
> 
> and for any OMAP drivers as well.  This gives:
> 
> arch/arm/mach-omap1/id.c
> arch/arm/mach-omap1/lcd_dma.c
> arch/arm/mach-omap1/io.c
> arch/arm/mach-omap1/ams-delta-fiq.c
> arch/arm/mach-omap2/gpmc.c
> arch/arm/mach-omap2/id.c
> arch/arm/mach-omap2/io.c
> arch/arm/plat-omap/ocpi.c
> arch/arm/plat-omap/mcbsp.c
> arch/arm/plat-omap/omap_device.c
> arch/arm/plat-omap/mux.c
> arch/arm/plat-omap/devices.c
> arch/arm/plat-omap/io.c
> arch/arm/plat-omap/dma.c
> arch/arm/plat-omap/dmtimer.c
> arch/arm/plat-omap/mailbox.c
> 
> which probably should all be fixed before any more of these errors
> spring up.

Except for the ones that have module.h included as that already
includes export.h. At least the dmtimer.c will be moved to drivers,
and could be a loadable module so module.h is better there.

Anyways, will check these and post patches.

Regards,

Tony

OMAP CRAP: The Continuing Story Of Brokenness

[Tony Lindgren]

Tomi,

* Russell King - ARM Linux <linux@arm.linux.org.uk> [111107 09:12]:

> drivers/video/omap/dispc.c:276: warning: data definition has no type or storage class
> drivers/video/omap/dispc.c:276: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> drivers/video/omap/dispc.c:276: warning: parameter names (without types) in function declaration
> drivers/video/omap/dispc.c:286: warning: data definition has no type or storage class
> drivers/video/omap/dispc.c:286: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> drivers/video/omap/dispc.c:286: warning: parameter names (without types) in function declaration
> drivers/video/omap/dispc.c:320: warning: data definition has no type or storage class
> drivers/video/omap/dispc.c:320: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> drivers/video/omap/dispc.c:320: warning: parameter names (without types) in function declaration
> drivers/video/omap/dispc.c:328: warning: data definition has no type or storage class
> drivers/video/omap/dispc.c:328: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> drivers/video/omap/dispc.c:328: warning: parameter names (without types) in function declaration
> drivers/video/omap/dispc.c:863: warning: data definition has no type or storage class
> drivers/video/omap/dispc.c:863: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> drivers/video/omap/dispc.c:863: warning: parameter names (without types) in function declaration
> drivers/video/omap/dispc.c:883: warning: data definition has no type or storage class
> drivers/video/omap/dispc.c:883: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> drivers/video/omap/dispc.c:883: warning: parameter names (without types) in function declaration

Care to queue something for drivers/video/omap warnings above?
 
> It might be an idea to do this:
> 
> grep -rl EXPORT_SYMBOL arch/arm/*omap* | xargs grep -L linux/export.h
> 
> and for any OMAP drivers as well.  This gives:
> 
> arch/arm/mach-omap1/id.c
> arch/arm/mach-omap1/lcd_dma.c
> arch/arm/mach-omap1/io.c
> arch/arm/mach-omap1/ams-delta-fiq.c
> arch/arm/mach-omap2/gpmc.c
> arch/arm/mach-omap2/id.c
> arch/arm/mach-omap2/io.c
> arch/arm/plat-omap/ocpi.c
> arch/arm/plat-omap/mcbsp.c
> arch/arm/plat-omap/omap_device.c
> arch/arm/plat-omap/mux.c
> arch/arm/plat-omap/devices.c
> arch/arm/plat-omap/io.c
> arch/arm/plat-omap/dma.c
> arch/arm/plat-omap/dmtimer.c
> arch/arm/plat-omap/mailbox.c
> 
> which probably should all be fixed before any more of these errors
> spring up.

I'll add the following patch to fix the remaining arch/arm/*omap*/
warnings in fixes branch.

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Mon, 7 Nov 2011 11:58:55 -0800
Subject: [PATCH] ARM: OMAP: Fix export.h or module.h includes

Commit 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb (Merge branch
'modsplit-Oct31_2011'...) caused some build errors. Fix these
and make sure we always have export.h or module.h included
for MODULE_ and EXPORT_SYMBOL users:

$ grep -rl ^MODULE_ arch/arm/*omap*/*.c | xargs \
  grep -L linux/module.h
arch/arm/mach-omap2/dsp.c
arch/arm/mach-omap2/mailbox.c
arch/arm/mach-omap2/omap-iommu.c
arch/arm/mach-omap2/smartreflex.c

Also check we either have export.h or module.h included
for the files exporting symbols:

$ grep -rl EXPORT_SYMBOL arch/arm/*omap*/*.c | xargs \
  grep -L linux/export.h | xargs grep -L linux/module.h

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -18,6 +18,7 @@
  * of the OMAP PM core code.
  */
 
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include "cm2xxx_3xxx.h"
 #include "prm2xxx_3xxx.h"
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -10,6 +10,7 @@
  * for more details.
  */
 
+#include <linux/module.h>
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/platform_device.h>
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/module.h>
 #include <linux/platform_device.h>
 
 #include <plat/iommu.h>
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -17,6 +17,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/clk.h>
 #include <linux/io.h>

OMAP CRAP: The Continuing Story Of Brokenness

[Tomi Valkeinen]

Hi Tony,

On Mon, 2011-11-07 at 12:26 -0800, Tony Lindgren wrote:
> Tomi,
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [111107 09:12]:
> 
> > drivers/video/omap/dispc.c:276: warning: data definition has no type or storage class
> > drivers/video/omap/dispc.c:276: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> > drivers/video/omap/dispc.c:276: warning: parameter names (without types) in function declaration
> > drivers/video/omap/dispc.c:286: warning: data definition has no type or storage class
> > drivers/video/omap/dispc.c:286: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> > drivers/video/omap/dispc.c:286: warning: parameter names (without types) in function declaration
> > drivers/video/omap/dispc.c:320: warning: data definition has no type or storage class
> > drivers/video/omap/dispc.c:320: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> > drivers/video/omap/dispc.c:320: warning: parameter names (without types) in function declaration
> > drivers/video/omap/dispc.c:328: warning: data definition has no type or storage class
> > drivers/video/omap/dispc.c:328: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> > drivers/video/omap/dispc.c:328: warning: parameter names (without types) in function declaration
> > drivers/video/omap/dispc.c:863: warning: data definition has no type or storage class
> > drivers/video/omap/dispc.c:863: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> > drivers/video/omap/dispc.c:863: warning: parameter names (without types) in function declaration
> > drivers/video/omap/dispc.c:883: warning: data definition has no type or storage class
> > drivers/video/omap/dispc.c:883: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> > drivers/video/omap/dispc.c:883: warning: parameter names (without types) in function declaration
> 
> Care to queue something for drivers/video/omap warnings above?

Sure, I'll send a patch for -rc2. 

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111108/f63af45c/attachment.sig>

OMAP CRAP: The Continuing Story Of Brokenness

[Felipe Balbi]

Hi,

On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [111106 03:44]:
> > Yet again I find that I'm having to email about crap on OMAP3.
> > 
> > I'm getting really fed up with OMAP stuff which keeps breaking in
> > idiotic ways - and the way there's fatal build errors at EVERY merge
> > window.  The OMAP workflow is totally broken.  Something MUST change
> > in the way the OMAP community works to stop the continual breakage
> > at every single bloody merge window.
> 
> Hmm he following fixes are queued elsewhere and now merged:
> 
> omap_hsmmc: fix missing parenthesis in pr_info
> PM / OPP: Fix build when CONFIG_PM_OPP is not set 
> net: Add back alignment for size for __alloc_skb
> 
> Or have you seen some other build errors?
> 
> FYI, now all the compile warnings are finally gone with what
> I have in fixes branch.
>  
> > One is new:
> > 
> > WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
> > usb_musb_init: could not find omap_hwmod for usb_otg_hs
> > Modules linked in:
> > Backtrace:
> > [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:0000008d
> > [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
> > [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
> >  r8:00000000 r7:00000013 r6:c0374b05 r5:c03f06e4 r4:c0374190
> > [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c03ceb54>] (usb_musb_init+0xc0/0x174)
> >  r3:c02df894 r2:c03707d9
> > [<c03cea94>] (usb_musb_init+0x0/0x174) from [<c03ce02c>] (omap_ldp_init+0xb0/0x100)
> >  r6:c003e7d8 r5:c03f06e4 r4:c04053e4
> > [<c03cdf7c>] (omap_ldp_init+0x0/0x100) from [<c03c6788>] (customize_machine+0x24/0x30)
> >  r4:c03f03a8
> > [<c03c6764>] (customize_machine+0x0/0x30) from [<c0008710>] (do_one_initcall+0x9c/0x164)
> > [<c0008674>] (do_one_initcall+0x0/0x164) from [<c03c3284>] (kernel_init+0x7c/0x120)
> > [<c03c3208>] (kernel_init+0x0/0x120) from [<c003e7d8>] (do_exit+0x0/0x62c)
> >  r5:c03c3208 r4:00000000
> 
> Felipe, care to check what the status of the musb hwmod issue
> above is?

doesn't seem to be a bug on usb-musb.c, looking at
omap_hwmod_3xxx_data.c:

$ git grep -A 1 -e "static struct omap_hwmod \w\+usbhsotg_hwmod = {"\
	arch/arm/mach-omap2/omap_hwmod*data.c
arch/arm/mach-omap2/omap_hwmod_2430_data.c:static struct omap_hwmod omap2430_usbhsotg_hwmod = {
arch/arm/mach-omap2/omap_hwmod_2430_data.c-     .name           = "usb_otg_hs",
--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c:static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c-     .name           = "usb_otg_hs",
--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c:static struct omap_hwmod am35xx_usbhsotg_hwmod = {
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c-     .name           = "am35x_otg_hs",

in fact, that part of the code hasn't changed during this merge window:

$ git log v3.1..linus/master -- arch/arm/mach-omap2/usb-musb.c

commit f718e2c034bf6ff872106344935006230764cb12
Author: Benoit Cousson <b-cousson@ti.com>
Date:   Wed Aug 10 15:30:09 2011 +0200

    ARM: OMAP2+: devices: Remove all omap_device_pm_latency structures
    
    Remove all these duplicated structures since a default one is now
    available.
    
    Signed-off-by: Benoit Cousson <b-cousson@ti.com>
    Signed-off-by: Kevin Hilman <khilman@ti.com>

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index d86af3c..47fb5d6 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -60,14 +60,6 @@ static struct musb_hdrc_platform_data musb_plat = {
 
 static u64 musb_dmamask = DMA_BIT_MASK(32);
 
-static struct omap_device_pm_latency omap_musb_latency[] = {
-	{
-		.deactivate_func	= omap_device_idle_hwmods,
-		.activate_func		= omap_device_enable_hwmods,
-		.flags			= OMAP_DEVICE_LATENCY_AUTO_ADJUST,
-	},
-};
-
 static void usb_musb_mux_init(struct omap_musb_board_data *board_data)
 {
 	switch (board_data->interface_type) {
@@ -150,8 +142,7 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
                 return;
 
 	pdev = omap_device_build(name, bus_id, oh, &musb_plat,
-			       sizeof(musb_plat), omap_musb_latency,
-			       ARRAY_SIZE(omap_musb_latency), false);
+			       sizeof(musb_plat), NULL, 0, false);
 	if (IS_ERR(pdev)) {
 		pr_err("Could not build omap_device for %s %s\n",
 						name, oh_name);

commit c541c15fb5ab48c47bc9b90121538fd30d152f23
Merge: 5c30cdf be73246 7d33910 ab4eb8b dc9ca24
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Oct 4 09:47:06 2011 -0700

    Merge branches 'cleanup-part3', 'voltage', 'dmtimer' and 'l3' into dt-base

could the below be the bug ?

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3008e16..74f1454 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3232,7 +3232,6 @@ static __initdata struct omap_hwmod *omap3430es1_hwmods[] = {
 /* 3430ES2+-only hwmods */
 static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
 	&omap3xxx_dss_core_hwmod,
-	&omap3xxx_usbhsotg_hwmod,
 	NULL
 };
 
@@ -3240,6 +3239,7 @@ static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
 static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
 	&omap34xx_sr1_hwmod,
 	&omap34xx_sr2_hwmod,
+	&omap3xxx_usbhsotg_hwmod,
 	NULL
 };
 

clearly commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) is wrong at
thinking MUSB is only available on ES2+ revisions of OMAP3430.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111107/945e23bf/attachment.sig>

OMAP CRAP: The Continuing Story Of Brokenness

[S, Venkatraman]

On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Yet again I find that I'm having to email about crap on OMAP3.
>
> I'm getting really fed up with OMAP stuff which keeps breaking in
> idiotic ways - and the way there's fatal build errors at EVERY merge
> window. ?The OMAP workflow is totally broken. ?Something MUST change
> in the way the OMAP community works to stop the continual breakage
> at every single bloody merge window.
>
> One is new:
>
> WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
> usb_musb_init: could not find omap_hwmod for usb_otg_hs
> Modules linked in:
> Backtrace:
> [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:0000008d
> [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
> [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
> ?r8:00000000 r7:00000013 r6:c0374b05 r5:c03f06e4 r4:c0374190
> [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c03ceb54>] (usb_musb_init+0xc0/0x174)
> ?r3:c02df894 r2:c03707d9
> [<c03cea94>] (usb_musb_init+0x0/0x174) from [<c03ce02c>] (omap_ldp_init+0xb0/0x100)
> ?r6:c003e7d8 r5:c03f06e4 r4:c04053e4
> [<c03cdf7c>] (omap_ldp_init+0x0/0x100) from [<c03c6788>] (customize_machine+0x24/0x30)
> ?r4:c03f03a8
> [<c03c6764>] (customize_machine+0x0/0x30) from [<c0008710>] (do_one_initcall+0x9c/0x164)
> [<c0008674>] (do_one_initcall+0x0/0x164) from [<c03c3284>] (kernel_init+0x7c/0x120)
> [<c03c3208>] (kernel_init+0x0/0x120) from [<c003e7d8>] (do_exit+0x0/0x62c)
> ?r5:c03c3208 r4:00000000
> ---[ end trace 1b75b31a2719ed1c ]---
> ?omap_timer.1: alias fck already exists
> ?omap_timer.2: alias fck already exists
> ?omap_timer.3: alias fck already exists
> ?omap_timer.4: alias fck already exists
> ?omap_timer.5: alias fck already exists
> ?omap_timer.6: alias fck already exists
> ?omap_timer.7: alias fck already exists
> ?omap_timer.8: alias fck already exists
> ?omap_timer.9: alias fck already exists
> ?omap_timer.10: alias fck already exists
> ?omap_timer.11: alias fck already exists
> ?omap_timer.12: alias fck already exists
> ?omap-mcbsp.2: alias fck already exists
> ?omap-mcbsp.3: alias fck already exists
>
> And this, which I reported on August 26th - so it's now over three months
> old is still there. ?Clearly, no one cares about this driver so shall I
> delete the omap-hsmmc driver, or is someone going to clean up their crap?
> Or shall we revert all those patches for adding the asynchronous mapping
> of MMC requests until the _REGRESSION_ is fixed properly?
>
> mmcblk0: error -84 transferring data, sector 149209, nr 56, cmd response 0x900,
> card status 0xb00
> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:865 check_unmap+0x1b0/0x76c()
> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000080000000] [size=16384 bytes]
> Modules linked in:
> Backtrace:
> [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c1af7cb0 r6:c018bfc8 r5:c038b4ff r4:00000361
> [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70)
> [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40)
> ?r8:c1af7d48 r7:00000000 r6:00004000 r5:00000000 r4:80000000
> [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c018bfc8>] (check_unmap+0x1b0/0x76c)
> ?r3:c0375450 r2:c038b8f7
> [<c018be18>] (check_unmap+0x0/0x76c) from [<c018c6fc>] (debug_dma_unmap_sg+0x100/0x134)
> [<c018c5fc>] (debug_dma_unmap_sg+0x0/0x134) from [<c0019848>] (dma_unmap_sg+0x24/0x7c)
> [<c0019824>] (dma_unmap_sg+0x0/0x7c) from [<c021112c>] (omap_hsmmc_post_req+0x48/0x54)
> [<c02110e4>] (omap_hsmmc_post_req+0x0/0x54) from [<c0204a8c>] (mmc_start_req+0x9c/0x128)
> ?r4:c1ab2000
> [<c02049f0>] (mmc_start_req+0x0/0x128) from [<c020e6a4>] (mmc_blk_issue_rw_rq+0x80/0x4e8)
> ?r8:c1aefc00 r7:c1aed800 r6:c1aefc24 r5:c1aed800 r4:c1aefc24
> [<c020e624>] (mmc_blk_issue_rw_rq+0x0/0x4e8) from [<c020ef04>] (mmc_blk_issue_rq+0x3f8/0x428)
> [<c020eb0c>] (mmc_blk_issue_rq+0x0/0x428) from [<c020fa8c>] (mmc_queue_thread+0xa0/0x104)
> [<c020f9ec>] (mmc_queue_thread+0x0/0x104) from [<c0055bf0>] (kthread+0x88/0x90)
> [<c0055b68>] (kthread+0x0/0x90) from [<c003e7d8>] (do_exit+0x0/0x62c)
> ?r7:00000013 r6:c003e7d8 r5:c0055b68 r4:c1831c5c
> ---[ end trace 1b75b31a2719ed1e ]---
>

This hsmmc issue is fixed by this patch sent out today..
http://marc.info/?l=linux-mmc&m=132068306510134&w=2