All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Per Förlin" <per.forlin@stericsson.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Per Forlin <per.forlin@linaro.org>, Chris Ball <cjb@laptop.org>
Subject: Re: OMAP CRAP: The Continuing Story Of Brokenness
Date: Sun, 6 Nov 2011 16:29:54 +0100	[thread overview]
Message-ID: <4EB6A7F2.1010606@stericsson.com> (raw)
In-Reply-To: <20111106121829.GB15294@n2100.arm.linux.org.uk>

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

WARNING: multiple messages have this Message-ID (diff)
From: per.forlin@stericsson.com (Per Förlin)
To: linux-arm-kernel@lists.infradead.org
Subject: OMAP CRAP: The Continuing Story Of Brokenness
Date: Sun, 6 Nov 2011 16:29:54 +0100	[thread overview]
Message-ID: <4EB6A7F2.1010606@stericsson.com> (raw)
In-Reply-To: <20111106121829.GB15294@n2100.arm.linux.org.uk>

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

  parent reply	other threads:[~2011-11-06 15:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-06 12:18 OMAP CRAP: The Continuing Story Of Brokenness Russell King - ARM Linux
2011-11-06 12:18 ` Russell King - ARM Linux
2011-11-06 13:06 ` S, Venkatraman
2011-11-06 13:06   ` S, Venkatraman
2011-11-06 15:29 ` Per Förlin [this message]
2011-11-06 15:29   ` Per Förlin
2011-11-07 17:26 ` Tony Lindgren
2011-11-07 17:26   ` Tony Lindgren
2011-11-07 17:46   ` Russell King - ARM Linux
2011-11-07 17:46     ` Russell King - ARM Linux
2011-11-07 17:56     ` Tony Lindgren
2011-11-07 17:56       ` Tony Lindgren
2011-11-07 20:26     ` Tony Lindgren
2011-11-07 20:26       ` Tony Lindgren
2011-11-08  8:13       ` Tomi Valkeinen
2011-11-08  8:13         ` Tomi Valkeinen
2011-11-07 17:51   ` Felipe Balbi
2011-11-07 17:51     ` Felipe Balbi
2011-11-07 17:30 ` S, Venkatraman
2011-11-07 17:30   ` S, Venkatraman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB6A7F2.1010606@stericsson.com \
    --to=per.forlin@stericsson.com \
    --cc=cjb@laptop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=per.forlin@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.