[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110110 10:51]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110107 08:12]:
> > On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
> > > Anyways, I can debug the DEBUG_LL booting issue further if the patch
> > > I posted does not help.
> > 
> > This is what I ended up with earlier today to make the debug code work
> > both in the decompressor and in the kernel - once I had it working I
> > haven't bothered putting any more effort into it.
> 
> Hmm I have DEBUG_LL working fine (execept not for the uncompress code).
> 
> Looks like the only issue I have with my 4430 es1.0 blaze board is
> that it won't boot reliably unless I disable l2x0_init.
> 
> Have you guys seen this issue?
> 
> Of course there are all kinds of omap4 warnings there, but after
> disabling l2x0_init I was able to run apt-get dist-upgrade on my
> board. This is with what I have queued up in omap-fixes.

Here's one more es1.0 fix after the recent USB changes.

Regards,

Tony


Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Jan 11 15:03:03 2011 -0800

    omap4: Fix ULPI PHY init for ES1.0 SDP
    
    Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
    enable the ehci port on 4430SDP) added code to enable EHCI
    support on 4430sdp board.
    
    Looks like the ULPI pin does not seem to be muxed properly on ES1.0
    SDP and this causes the system to reboot when the ULPI PHY is
    enabled.
    
    Fix this by muxing the pin, this is the same setting for
    both ES1.0 and ES2.0. Also add checking for gpio_request.
    
    Cc: Keshava Munegowda <keshava_mgowda at ti.com
    Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
+	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else
@@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
 	omap4_twl6030_hsmmc_init(mmc);
 
 	/* Power on the ULPI PHY */
-	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
-		/* FIXME: Assumes pad is already muxed for GPIO mode */
-		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+	if (status)
+		pr_err("%s: Could not get USBB1 PHY GPIO\n");
+	else
 		gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
-	}
+
 	usb_ehci_init(&ehci_pdata);
 	usb_musb_init(&musb_board_data);
 

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Anand Gadiyar]

Tony Lindgren wrote:
> Here's one more es1.0 fix after the recent USB changes.
>
> Regards,
>
> Tony
>
>
> Author: Tony Lindgren <tony@atomide.com>
> Date:   Tue Jan 11 15:03:03 2011 -0800
>
>     omap4: Fix ULPI PHY init for ES1.0 SDP
>
>     Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
>     enable the ehci port on 4430SDP) added code to enable EHCI
>     support on 4430sdp board.
>
>     Looks like the ULPI pin does not seem to be muxed properly on ES1.0
>     SDP and this causes the system to reboot when the ULPI PHY is
>     enabled.
>
>     Fix this by muxing the pin, this is the same setting for
>     both ES1.0 and ES2.0. Also add checking for gpio_request.
>
>     Cc: Keshava Munegowda <keshava_mgowda@ti.com
>     Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
>
>  #ifdef CONFIG_OMAP_MUX
>  static struct omap_board_mux board_mux[] __initdata = {
> +	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
>  	{ .reg_offset = OMAP_MUX_TERMINATOR },
>  };
>  #else
> @@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
>  	omap4_twl6030_hsmmc_init(mmc);
>
>  	/* Power on the ULPI PHY */
> -	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> -		/* FIXME: Assumes pad is already muxed for GPIO mode */
> -		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
VMDM_3V3");
> +	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
VMDM_3V3");
> +	if (status)
> +		pr_err("%s: Could not get USBB1 PHY GPIO\n");

Tony,

This throws up a build warning as there's no parameter corresponding to
the %s. Showed up in linux-next as of today.

- Anand

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Russell King - ARM Linux]

On Thu, Jan 13, 2011 at 02:22:06PM +0530, Anand Gadiyar wrote:
> Tony Lindgren wrote:
> >  	/* Power on the ULPI PHY */
> > -	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> > -		/* FIXME: Assumes pad is already muxed for GPIO mode */
> > -		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> VMDM_3V3");
> > +	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> VMDM_3V3");
> > +	if (status)
> > +		pr_err("%s: Could not get USBB1 PHY GPIO\n");
> 
> Tony,
> 
> This throws up a build warning as there's no parameter corresponding to
> the %s. Showed up in linux-next as of today.

It's pretty obvious that the above is wrong, and the compiler would
have caught it with a warning when building it.  Was the above patch
not build-tested before it was committed?

Given the very sorry state of OMAP in mainline at present, I'm surprised
that this kind of stuff is still going on...

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> On Thu, Jan 13, 2011 at 02:22:06PM +0530, Anand Gadiyar wrote:
> > Tony Lindgren wrote:
> > >  	/* Power on the ULPI PHY */
> > > -	if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> > > -		/* FIXME: Assumes pad is already muxed for GPIO mode */
> > > -		gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> > VMDM_3V3");
> > > +	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> > VMDM_3V3");
> > > +	if (status)
> > > +		pr_err("%s: Could not get USBB1 PHY GPIO\n");
> > 
> > Tony,
> > 
> > This throws up a build warning as there's no parameter corresponding to
> > the %s. Showed up in linux-next as of today.

Oops, sorry, will fix.
 
> It's pretty obvious that the above is wrong, and the compiler would
> have caught it with a warning when building it.  Was the above patch
> not build-tested before it was committed?

Sure, boot tested it but missed the warning though.
 
> Given the very sorry state of OMAP in mainline at present, I'm surprised
> that this kind of stuff is still going on...

At least I boot test the patches I send..

Regards,

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Russell King - ARM Linux]

On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > that this kind of stuff is still going on...
> 
> At least I boot test the patches I send..

Which is why OMAP3 and OMAP4 can't be built in mainline because they
spit out lots of compile errors in the OMAP code...  As they won't
even compile they couldn't have been boot tested.

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 08:49]:
> On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > that this kind of stuff is still going on...
> > 
> > At least I boot test the patches I send..
> 
> Which is why OMAP3 and OMAP4 can't be built in mainline because they
> spit out lots of compile errors in the OMAP code...  As they won't
> even compile they couldn't have been boot tested.

Huh? I have fixes queued up for the issues that showed up with
merges with various other trees.

I certainly make sure everything I merge is compile and boot
tested. Sure there are still tons of issues still remaining,
but people are working on those. That's why we have the -rc
releases.

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Paul Walmsley]

On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:

> On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > that this kind of stuff is still going on...
> > 
> > At least I boot test the patches I send..
> 
> Which is why OMAP3 and OMAP4 can't be built in mainline because they
> spit out lots of compile errors in the OMAP code...  As they won't
> even compile they couldn't have been boot tested.

Current mainline != the patches that Tony sent to Linus[1].

The patches that Tony sent to Linus, which Linus merged, build fine
with omap2plus_defconfig[2].


- Paul


1. Lindgren, Tony.  _[GIT PULL] omap changes for v2.6.38_.
   Posted to the linux-kernel mailing list on 6 January 2011.
   http://www.gossamer-threads.com/lists/linux/kernel/1324357 (among 
   others)

2. Compilation log of the patches that Tony submitted for the 2.6.38 merge 
   window (included below)

---

$ git log mainline/master --pretty=oneline | fgrep omap-for-linus |head -1
01539ba2a706ab7d35fc0667dff919ade7f87d63 Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
$ git show 01539ba2a706ab7d35fc0667dff919ade7f87d63 |head -5
commit 01539ba2a706ab7d35fc0667dff919ade7f87d63
Merge: 9e9bc97 dc69d1a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jan 6 19:13:58 2011 -0800
$ git checkout dc69d1a
HEAD is now at dc69d1a... omap2: Make OMAP2PLUS select OMAP_DM_TIMER
$ make mrproper
$ make omap2plus_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
$ make -j2
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK     include/linux/version.h
  UPD     include/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  HOSTCC  scripts/genksyms/genksyms.o
  Generating include/generated/mach-types.h
  CC      kernel/bounds.s
  GEN     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  SHIPPED scripts/genksyms/lex.c
  SHIPPED scripts/genksyms/parse.h
  SHIPPED scripts/genksyms/keywords.c
  SHIPPED scripts/genksyms/parse.c
  HOSTCC  scripts/genksyms/lex.o
  GEN     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  HOSTCC  scripts/genksyms/parse.o
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
  HOSTLD  scripts/genksyms/genksyms
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/pnmtologo
  HOSTCC  scripts/mod/modpost.o
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/bin2c
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  CC      init/main.o
  HOSTCC  usr/gen_init_cpio
  GEN     usr/initramfs_data.cpio
  AS      usr/initramfs_data.o
  LD      usr/built-in.o
  CC      arch/arm/nwfpe/fpa11.o
  CC      arch/arm/nwfpe/fpa11_cpdo.o
  CC      arch/arm/nwfpe/fpa11_cpdt.o
  CC      arch/arm/nwfpe/fpa11_cprt.o
  CC      arch/arm/nwfpe/fpmodule.o
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/do_mounts.o
  CC      arch/arm/nwfpe/fpopcode.o
  CC      arch/arm/nwfpe/softfloat.o
  CC      init/do_mounts_rd.o
  CC      arch/arm/nwfpe/single_cpdo.o
  CC      init/do_mounts_initrd.o
  CC      arch/arm/nwfpe/double_cpdo.o
  AS      arch/arm/nwfpe/entry.o
  LD      arch/arm/nwfpe/nwfpe.o
  LD      arch/arm/nwfpe/built-in.o
  CC      init/initramfs.o
  CC      init/calibrate.o
  CC      init/version.o
  LD      init/mounts.o
  CC      arch/arm/vfp/vfpmodule.o
  LD      init/built-in.o
  CC      arch/arm/kernel/elf.o
  AS      arch/arm/vfp/entry.o
  AS      arch/arm/vfp/vfphw.o
  CC      arch/arm/vfp/vfpsingle.o
  AS      arch/arm/kernel/entry-armv.o
  AS      arch/arm/kernel/entry-common.o
  CC      arch/arm/kernel/irq.o
  CC      arch/arm/vfp/vfpdouble.o
  CC      arch/arm/kernel/process.o
  LD      arch/arm/vfp/vfp.o
  LD      arch/arm/vfp/built-in.o
  CC      arch/arm/mm/dma-mapping.o
  CC      arch/arm/kernel/ptrace.o
  CC      arch/arm/mm/extable.o
  CC      arch/arm/mm/fault.o
  CC      arch/arm/kernel/return_address.o
arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables"
arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables"
  CC      arch/arm/kernel/setup.o
  CC      arch/arm/mm/init.o
  CC      arch/arm/mm/iomap.o
  CC      arch/arm/kernel/signal.o
  CC      arch/arm/mm/fault-armv.o
  CC      arch/arm/kernel/sys_arm.o
  CC      arch/arm/mm/flush.o
  CC      arch/arm/kernel/stacktrace.o
  CC      arch/arm/mm/ioremap.o
  CC      arch/arm/kernel/time.o
  CC      arch/arm/mm/mmap.o
  CC      arch/arm/kernel/traps.o
  CC      arch/arm/mm/pgd.o
  CC      arch/arm/mm/mmu.o
  CC      arch/arm/kernel/leds.o
  CC      arch/arm/kernel/armksyms.o
  CC      arch/arm/mm/vmregion.o
  CC      arch/arm/mm/proc-syms.o
  CC      arch/arm/kernel/module.o
  CC      arch/arm/mm/alignment.o
  CC      arch/arm/kernel/smp.o
  AS      arch/arm/mm/abort-ev6.o
  AS      arch/arm/mm/abort-ev7.o
  AS      arch/arm/mm/pabort-v6.o
  AS      arch/arm/mm/pabort-v7.o
  AS      arch/arm/mm/cache-v6.o
  AS      arch/arm/mm/cache-v7.o
  CC      arch/arm/mm/copypage-v6.o
  CC      arch/arm/mm/context.o
  CC      a2/powerdomains44xx_data.o
  CC      arch/arm/mach-omap2/clockdomain.o
  CC      arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.o
  CC      arch/arm/mach-omap2/clockdomains44xx_data.o
  CC      arch/arm/mach-omap2/clock.o
  CC      arch/arm/mach-omap2/clock_common_data.o
  CC      arch/arm/mach-omap2/clkt_dpll.o
  CC      kernel/exec_domain.o
  CC      arch/arm/mach-omap2/clkt_clksel.o
  CC      arch/arm/mach-omap2/clock2xxx.o
  CC      arch/arm/mach-omap2/clkt2xxx_sys.o
  CC      arch/arm/mach-omap2/clkt2xxx_dpllcore.o
  CC      kernel/panic.o
  CC      arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.o
  CC      arch/arm/mach-omap2/clkt2xxx_apll.o
  CC      arch/arm/mach-omap2/clkt2xxx_osc.o
  CC      kernel/printk.o
  CC      arch/arm/mach-omap2/clock2420_data.o
  CC      arch/arm/mach-omap2/clock2430.o
  CC      arch/arm/mach-omch/arm/mach-omap2/usb-musb.o
  CC      arch/arm/mach-omap2/usb-tusb6010.o
  CC      kernel/nsproxy.o
  CC      arch/arm/mach-omap2/usb-ehci.o
  CC      kernel/srcu.o
  CC      arch/arm/mach-omap2/gpmc-onenand.o
  CC      kernel/semaphore.o
  CC      arch/arm/mach-omap2/gpmc-nand.o
  CC      arch/arm/mach-omap2/gpmc-smc91x.o
  CC      kernel/notifier.o
  CC      arch/arm/mach-omap2/gpmc-smsc911x.o
  CC      kernel/ksysfs.o
  LD      arch/arm/mach-omap2/built-in.o
  CC      kernel/pm_qos_params.o
  CC      mm/bootmem.o
  CC      kernel/sched_clock.o
  CC      mm/filemap.o
  CC      kernel/cred.o
  CC      kernel/async.o
  CC      kernel/range.o
  CC      kernel/jump_label.o
  CC      mm/mempool.o
  CC      kernel/groups.o
  CC      mm/oom_kill.o
  CC      kernel/freezer.o
  CC      kernel/profile.o
  CC      mm/fadvise.o
  CC      mm/maccess.o
  CC      kernel/stacktrace.o
  CC      mm/page_alloc.o
  CC      kernel/irq/irqdesc.o
  CC      kernel/irq/handle.o
  CC      kernel/irq/manage.o
  CC      kernel/irq/spurious.o
  CC      kernel/irq/resend.o
  CC      mm/page-writeback.o
  CC      kernel/irq/chip.o
  CC      kernel/irq/dummychip.o
  CC      kernel/irq/devres.o
  CC      kernel/irq/autoprobe.o
  CC      mm/readahead.o
  CC      kernel/irq/proc.o
  CC      kernel/irq/pm.o
  LD      kernel/irq/built-in.o
  CC      kernel/power/main.o
  CC      mm/swap.o
  CC      kernel/power/console.o
  CC      kernel/power/process.o
  CC      mm/truncate.o
  CC      kernel/power/suspend.o
  CC      mm/vmscan.o
  CC      kernel/power/nvs.o
  CC      kernel/power/poweroff.o
  LD      kernel/power/built-in.o
  CC      kernel/time/timekeeping.o
  CC      kernel/time/ntp.o
  CC      kernel/time/clocksource.o
  CC      mm/shmem.o
  CC      kernel/time/jiffies.o
  CC      kernel/time/timer_list.o
  CC      kernel/time/timecompare.o
  CC      kernel/time/timeconv.o
  CC      kernel/time/clockevents.o
  CC      mm/prio_tree.o
  CC      mm/util.o
  CC      kernel/time/tick-common.o
  CC      kernel/time/tick-broadcast.o
  CC      mm/mmzone.o
  CC      kernel/time/tick-oneshot.o
  CC      mm/vmstat.o
  CC      kernel/time/tick-sched.o
  CC      kernel/time/timer_stats.o
  CC      mm/backing-dev.o
  LD      kernel/time/built-in.o
  CC      kernel/trace/trace_clock.o
  CC      kernel/trace/ring_buffer.o
  CC      mm/page_isolation.o
  CC      mm/mm_init.o
  CC      mm/mmu_context.o
  CC      mm/percpu.o
  CC      kernel/trace/trace.o
  CC      mm/fremap.o
  CC      mm/highmem.o
  CC      mm/madvise.o
  CC      mm/memory.o
  CC      kernel/trace/trace_output.o
  CC      kernel/trace/trace_stat.o
  CC      mm/mincore.o
  CC      kernel/trace/trace_printk.o
  CC      mm/mlock.o
  CC      kernel/trace/trace_sched_switch.o
  CC      mm/mmap.o
  CC      kernel/trace/trace_nop.o
  CC      kernel/trace/blktrace.o
  CC      mm/mprotect.o
  CC      kernel/trace/trace_events.o
  CC      mm/mremap.o
  CC      mm/msync.o
  CC      kernel/trace/trace_export.o
  CC      mm/rmap.o
  CC      kernel/trace/trace_event_perf.o
  CC      kernel/trace/trace_events_filter.o
  CC      mm/vmalloc.o
  CC      kernel/trace/trace_kprobe.o
  CC      mm/pagewalk.o
  CC      mm/init-mm.o
  CC      mm/memblock.o
  CC      kernel/trace/power-traces.o
  CC      mm/page_io.o
  CC      mm/swap_state.o
  LD      kernel/trace/built-in.o
  CC      kernel/mutex-debug.o
  CC      mm/swapfile.o
  CC      kernel/lockdep.o
  CC      mm/thrash.o
  CC      mm/dmapool.o
  CC      mm/slab.o
  CC      kernel/lockdep_proc.o
  CC      kernel/futex.o
  CC      kernel/rtmutex.o
  LD      mm/built-in.o
  CC      fs/open.o
  CC      kernel/smp.o
  CC      kernel/spinlock.o
  CC      kernel/uid16.o
  CC      fs/read_write.o
  CC      kernel/module.o
  CC      fs/file_table.o
  CC      fs/super.o
  CC      kernel/kallsyms.o
  CC      fs/char_dev.o
  CC      kernel/acct.o
  CC      fs/stat.o
  CC      kernel/kexec.o
  CC      fs/exec.o
  GZIP    kernel/config_data.gz
  CC      kernel/stop_machine.o
  CC      kernel/kprobes.o
  CC      fs/pipe.o
  CC      kernel/rcutree.o
  CC      fs/namei.o
  CC      kernel/utsname_sysctl.o
  CC      kernel/tracepoint.o
  CC      kernel/elfcore.o
  CC      kernel/sched_cpupri.o
  CC      kernel/irq_work.o
  CC      fs/fcntl.o
  CC      kernel/perf_event.o
  CC      fs/ioctl.o
  CC      fs/readdir.o
  CC      fs/select.o
  CC      fs/fifo.o
  CC      kernel/hw_breakpoint.o
  CC      fs/dcache.o
  CC      kernel/time.o
  IKCFG   kernel/config_data.h
  CC      kernel/configs.o
  CC      fs/inode.o
  LD      kernel/built-in.o
  CC      ipc/util.o
  CC      ipc/msgutil.o
  CC      fs/attr.o
  CC      ipc/msg.o
  CC      fs/bad_inode.o
  CC      ipc/sem.o
  CC      fs/file.o
  CC      fs/filesystems.o
  CC      ipc/shm.o
  CC      fs/namespace.o
  CC      ipc/ipcns_notifier.o
  CC      ipc/syscall.o
  CC      ipc/ipc_sysctl.o
  CC      ipc/mqueue.o
  CC      fs/seq_file.o
  CC      ipc/mq_sysctl.o
  CC      fs/xattr.o
  LD      ipc/built-in.o
  CC      fs/libfs.o
  CC      fs/fs-writeback.o
  CC      security/keys/gc.o
  CC      security/keys/key.o
  CC      security/keys/keyring.o
  CC      fs/pnode.o
  CC      fs/drop_caches.o
  CC      fs/splice.o
  CC      security/keys/keyctl.o
  CC      security/keys/permission.o
  CC      fs/sync.o
  CC      security/keys/process_keys.o
  CC      fs/utimes.o
  CC      security/keys/request_key.o
  CC      fs/stack.o
  CC      security/keys/request_key_auth.o
  CC      fs/fs_struct.o
  CC      security/keys/user_defined.o
  CC      fs/statfs.o
  rs/mtd/onenand/built-in.o
  LD      drivers/mtd/tests/built-in.o
  CC      drivers/mtd/ubi/vtbl.o
  CC      drivers/mtd/ubi/vmt.o
  CC      fs/ubifs/sb.o
  CC      drivers/mtd/ubi/upd.o
  CC      drivers/mtd/ubi/build.o
  CC      fs/ubifs/io.o
  CC      drivers/mtd/ubi/cdev.o
  CC      fs/ubifs/tnc.o
  CC      drivers/mtd/ubi/kapi.o
  CC      drivers/mtd/ubi/eba.o
  CC      fs/ubifs/master.o
  CC      fs/ubifs/scan.o
  CC      drivers/mtd/ubi/io.o
  CC      fs/ubifs/replay.o
  CC      drivers/mtd/ubi/wl.o
  CC      fs/ubifs/log.o
  CC      drivers/mtd/ubi/scan.o
  CC      fs/ubifs/commit.o
  CC      fs/ubifs/gc.o
  CC      drivers/mtd/ubi/misc.o
  LD      drivers/mtd/ubi/ubi.o
  LD      drivers/mtd/ubi/built-in.o
  LD      drivers/mtd/mtd.o
  LD      drivers/mtd/built-in.o
  CC      drivers/net/mii.o
  CC      fs/ubifs/orphan.o
  CC      fs/ubifs/budget.o
  LD      drivers/net/arm/built-in.o
  CC      drivers/net/phy/phy.o
  CC      fs/ubifs/find.o
  CC      drivers/net/phy/phy_device.o
  CC      fs/ubifs/tnc_commit.o
  CC      fs/ubifs/compress.o
  CC      drivers/net/phy/mdio_bus.o
  CC      fs/ubifs/lpt.o
  CC      drivers/net/phy/smsc.o
  LD      drivers/net/phy/libphy.o
  LD      drivers/net/phy/built-in.o
  CC      drivers/net/usb/asix.o
  CC      fs/ubifs/lprops.o
  CC      fs/ubifs/recovery.o
  CC      drivers/net/usb/cdc_ether.o
  CC      drivers/net/usb/net1080.o
  CC      fs/ubifs/ioctl.o
  CC      fs/ubifs/lpt_commit.o
  CC      drivers/net/usb/cdc_subset.o
  CC      drivers/net/usb/zaurus.o
  CC      fs/ubifs/tnc_misc.o
  CC      drivers/net/usb/usbnet.o
  LD      fs/ubifs/ubifs.o
  LD      fs/ubifs/built-in.o
  CC      fs/eventpoll.o
  CC      fs/anon_inodes.o
  LD      drivers/net/usb/built-in.o
  CC      fs/signalfd.o
  LD      drivers/net/wireless/built-in.o
  LD      drivers/net/wireless/libertas/built-in.o
  CC [M]  drivers/net/wireless/libertas/cfg.o
  CC      fs/timerfd.o
  CC      fs/eventfd.o
  CC [M]  drivers/net/wireless/libertas/cmd.o
  CC      fs/aio.o
  CC      fs/locks.o
  CC [M]  drivers/net/wireless/libertas/cmdresp.o
  CC [M]  drivers/net/wireless/libertas/debugfs.o
  CC      fs/binfmt_misc.o
  CC [M]  drivers/net/wireless/libertas/ethtool.o
  CC      fs/binfmt_script.o
  CC      fs/binfmt_elf.o
  CC [M]  drivers/net/wireless/libertas/main.o
  CC      fs/posix_acl.o
  CC [M]  drivers/net/wireless/libertas/rx.o
  CC      fs/xattr_acl.o
  CC      fs/dcookies.o
  CC [M]  drivers/net/wireless/libertas/tx.o
  LD      fs/built-in.o
  CC [M]  drivers/net/wireless/libertas/if_sdio.o
  LD      drivers/platform/built-in.o
  CC      drivers/power/power_supply_core.o
  CC      drivers/power/power_supply_sysfs.o
  LD      drivers/power/power_supply.o
  LD      drivers/power/built-in.o
  CC [M]  drivers/net/wireless/libertas/if_usb.o
  LD      sound/built-in.o
  CC [M]  sound/sound_core.o
  LD      sound/arm/built-in.o
  LD      sound/atmel/built-in.o
  LD      sound/core/oss/built-in.o
  CC [M]  sound/core/oss/mixer_oss.o
  LD [M]  drivers/net/wireless/libertas/libertas.o
  LD [M]  drivers/net/wireless/libertas/usb8xxx.o
  LD [M]  drivers/net/wireless/libertas/libertas_sdio.o
  CC      drivers/net/ks8851.o
  CC [M]  sound/core/oss/pcm_oss.o
  CC      drivers/net/ks8851_mll.o
  CC      drivers/net/Space.o
  CC      drivers/net/loopback.o
  CC [M]  sound/core/oss/pcm_plugin.o
  CC      drivers/net/smc91x.o
  CC [M]  sound/core/oss/io.o
  CC [M]  sound/core/oss/copy.o
  CC [M]  sound/core/oss/linear.o
  CC      drivers/net/smsc911x.o
  CC [M]  sound/core/oss/mulaw.o
  CC [M]  sound/core/oss/route.o
  CC [M]  sound/core/oss/rate.o
  LD [M]  sound/core/oss/snd-mixer-oss.o
  LD [M]  sound/core/oss/snd-pcm-oss.o
  CC [M]  sound/core/hwdep.o
  LD      drivers/net/built-in.o
  CC      drivers/regulator/core.o
  CC [M]  sound/core/memalloc.o
  CC [M]  sound/core/pcm.o
  CC      drivers/regulator/dummy.o
  CC      drivers/regulator/fixed.o
  CC [M]  sound/core/pcm_native.o
  CC      drivers/regulator/twl-regulator.o
  CC      drivers/regulator/tps65023-regulator.o
  CC      drivers/regulator/tps6507x-regulator.ooc/blackfin/built-in.o
  LD      sound/soc/codecs/built-in.o
  CC [M]  sound/soc/codecs/twl4030.o
  LD [M]  sound/soc/codecs/snd-soc-twl4030.o
  LD      sound/soc/davinci/built-in.o
  LD      sound/soc/ep93xx/built-in.o
  LD      sound/soc/fsl/built-in.o
  LD      sound/soc/imx/built-in.o
  LD      sound/soc/jz4740/built-in.o
  LD      sound/soc/kirkwood/built-in.o
  LD      sound/soc/nuc900/built-in.o
  LD      sound/soc/omap/built-in.o
  CC [M]  sound/soc/omap/omap-mcbsp.o
  CC      drivers/serial/8250_early.o
  CC      drivers/serial/omap-serial.o
  CC [M]  sound/soc/omap/omap-pcm.o
  CC [M]  sound/soc/omap/omap3pandora.o
  LD      drivers/serial/built-in.o
  CC      drivers/spi/spi.o
  CC      drivers/spi/omap2_mcspi.o
  LD [M]  sound/soc/omap/snd-soc-omap.o
  LD [M]  sound/soc/omap/snd-soc-omap-mcbsp.o
  LD [M]  sound/soc/omap/snd-soc-omap3pandora.o
  LD      sound/soc/pxa/built-in.o
  LD      sound/soc/s3c24xx/built-in.o
  LD      sound/soc/s6000/built-in.o
  LD      sound/soc/sh/built-in.o
  LD      sound/soc/txx9/built-in.o
  LD [M]  sound/soc/snd-soc-core.o
  LD      sound/sparc/built-in.o
  LD      sound/spi/built-in.o
  LD      sound/synth/built-in.o
  LD      sound/usb/built-in.o
  CC [M]  sound/usb/card.o
  LD    drivers/video/logo/logo_superh_vga16.c
  LOGO    drivers/video/logo/logo_blackfin_clut224.c
  LOGO    drivers/video/logo/logo_dec_clut224.c
  LOGO    drivers/video/logo/logo_m32r_clut224.c
  LOGO    drivers/video/logo/logo_mac_clut224.c
  LOGO    drivers/video/logo/logo_parisc_clut224.c
  LOGO    drivers/video/logo/logo_sgi_clut224.c
  LOGO    drivers/video/logo/logo_spe_clut224.c
  LOGO    drivers/video/logo/logo_sun_clut224.c
  LOGO    drivers/video/logo/logo_superh_clut224.c
  CC      drivers/video/logo/logo_linux_mono.o
  CC      drivers/video/logo/logo_linux_vga16.o
  CC      drivers/video/logo/logo_linux_cock.o
  CC      net/ipv4/ip_input.o
  CC      lib/bitrev.o
  CC      lib/crc-ccitt.o
  CC      net/ipv4/ip_fragment.o
  CC      lib/crc16.o
  CC      lib/crc-t10dif.o
  CC      lib/crc-itu-t.o
  HOSTCC  lib/gen_crc32table
  CC      lib/crc7.o
  CC      net/ipv4/ip_forward.o
  CC      lib/libcrc32c.o
  CC      lib/lzo/lzo1x_compress.o
  CC      lib/lzo/lzo1x_decompress.o
  CC      net/ipv4/ip_options.o
  LD      lib/lzo/lzo_compress.o
  LD      lib/lzo/lzo_decompress.o
  LD      lib/lzo/built-in.o
  CC      lib/zlib_deflate/deflate.o
  CC      lib/zlib_deflate/deftree.o
  CC      net/ipv4/ip_output.o
  CC      lib/zlib_deflate/deflate_syms.o
  LD      lib/zlib_deflate/zlib_deflate.o
  LD      lib/zlib_deflate/built-in.o
  CC      lib/zlib_inflate/inffast.o
  CC      lib/zlib_inflate/inflate.o
  CC      lib/zlib_inflate/infutil.o
  CC      lib/zlib_inflate/inftrees.o
  CC      lib/zlib_inflate/inflate_syms.o
  LD      lib/zlib_inflate/zlib_inflate.o
  LD      lib/zlib_inflate/built-in.o
  CC      lib/percpu_counter.o
  CC      net/ipv4/ip_sockglue.o
  CC      lib/nlattr.o
  CC      lib/atomic64.o
  CC      lib/argv_split.o
  CC      net/ipv4/inet_hashtables.o
  CC      lib/cmdline.o
  CC      lib/cpumask.o
  CC      lib/ctype.o
  CC      lib/dec_and_lock.o
  CC      lib/decompress.o
  CC      lib/decompress_inflate.o
  CC      net/ipv4/inet_timewait_sock.o
  CC      lib/dump_stack.o
  CC      lib/extable.o
  CC      lib/flex_array.o
  CC      lib/idr.o
  CC      net/ipv4/inet_connection_sock.o
  CC      lib/int_sqrt.o
  CC      lib/ioremap.o
  CC      lib/irq_regs.o
  CC      lib/is_single_threaded.o
  CC      net/ipv4/tcp.o
  CC      lib/klist.o
  CC      lib/kobject.o
  CC      lib/kobject_uevent.o
  CC      lib/kref.o
  CC      net/ipv4/tcp_input.o
  CC      lib/plist.o
  CC      lib/prio_heap.o
  CC      lib/prio_tree.o
  CC      lib/proportions.o
  CC      lib/radix-tree.o
  CC      lib/ratelimit.o
  CC      lib/rbtree.o
  CC      lib/reciprocal_div.o
  CC      lib/rwsem-spinlock.o
  CC      lib/sha1.o
  CC      lib/show_mem.o
  CC      lib/string.o
  CC      net/ipv4/tcp_output.o
  CC      lib/vsprintf.o
  GEN     lib/crc32table.h
  AR      lib/lib.a
  CC      lib/crc32.o
  CC      net/ipv4/tcp_timer.o
  LD      lib/built-in.o
  CC      net/ipv4/tcp_ipv4.o
  CC      net/ipv4/tcp_minisocks.o
  CC      net/ipv4/tcp_cong.o
  CC      net/ipv4/datagram.o
  CC      net/key/af_key.o
  CC      net/ipv4/raw.o
  CC      net/ipv4/udp.o
  LD      net/key/built-in.o
  CC      net/ipv4/udplite.o
  CC      net/ipv4/arp.o
  CC      net/ipv4/icmp.o
  CC      net/ipv4/devinet.o
  CC      net/ipv4/af_inet.o
  LD      net/mac80211/built-in.o
  CC [M]  net/mac80211/main.o
  CC      net/ipv4/igmp.o
  CC [M]  net/mac80211/status.o
  CC [M]  net/mac80211/sta_info.o
  CC [M]  net/mac80211/wep.o
  CC      net/ipv4/fib_frontend.o
  CC [M]  net/mac80211/wpa.o
  CC [M]  net/mac80211/scan.o
  CC      net/ipv4/fib_semantics.o
  CC      net/ipv4/inet_fragment.o
  CC [M]  net/mac80211/offchannel.o
  CC      net/ipv4/sysctl_net_ipv4.o
  CC [M]  net/mac80211/ht.o
  CC      net/ipv4/fib_hash.o
  CC [M]  net/mac80211/agg-tx.o
  CC      net/ipv4/proc.o
  CC      net/ipv4/xfrm4_mode_beet.o
  CC [M]  net/mac80211/agg-rx.o
  CC      net/ipv4/xfrm4_mode_transport.o
  CC [M]  net/mac80211/ibss.o
  CC      net/ipv4/xfrm4_mode_tunnel.o
  CC [M]  net/mac80211/mlme.o
  CC      net/ipv4/ipconfig.o
  CC [M]  net/mac80211/work.o
  CC      net/ipv4/netfilter.o
  CC [M]  net/mac80211/iface.o
  LD      net/ipv4/netfilter/built-in.o
  CC      net/ipv4/inet_diag.o
  CC [M]  net/mac80211/rate.o
  CC      net/ipv4/tcp_diag.o
  CC      net/ipv4/tcp_cubic.o
  CC [M]  net/mac80211/michael.o
  CC [M]  net/mac80211/tkip.o
  CC      net/ipv4/xfrm4_policy.o
  CC [M]  net/mac80211/aes_ccm.o
  CC      net/ipv4/xfrm4_state.o
  CC [M]  net/mac80211/aes_cmac.o
  CC      net/ipv4/xfrm4_input.o
  CC [M]  net/mac80211/cfg.o
  CC      net/ipv4/xfrm4_output.o
  CC [M]  net/mac80211/rx.o
  LD      net/ipv4/built-in.o
  CC [M]  net/mac80211/spectmgmt.o
  CC [M]  net/mac80211/tx.o
  CC      net/netfilter/core.o
  CC      net/netfilter/nf_log.o
  CC [M]  net/mac80211/key.o
  CC      net/netfilter/nf_queue.o
  CC [M]  net/mac80211/util.o
  CC      net/netfilter/nf_sockopt.o
  CC [M]  net/mac80211/wme.o
  LD      net/netfilter/netfilter.o
  LD      net/netfilter/built-in.o
  CC [M]  net/mac80211/event.o
  CC [M]  net/mac80211/chan.o
  CC [M]  net/mac80211/pm.o
  CC [M]  net/mac80211/rc80211_pid_algo.o
  CC [M]  net/mac80211/rc80211_minstrel.o
  CC [M]  net/mac80211/rc80211_minstrel_ht.o
  CC      net/netlink/af_netlink.o
  LD [M]  net/mac80211/mac80211.o
  CC      net/packet/af_packet.o
  CC      net/netlink/genetlink.o
  LD      net/packet/built-in.o
  CC      net/sched/sch_generic.o
  CC      net/sched/sch_mq.o
  LD      net/netlink/built-in.o
  CC      net/sunrpc/clnt.o
  LD      net/sched/built-in.o
  CC      net/unix/af_unix.o
  CC      net/sunrpc/xprt.o
  CC      net/unix/garbage.o
  CC      net/unix/sysctl_net_unix.o
  CC      net/sunrpc/socklib.o
  LD      net/unix/unix.o
  LD      net/unix/built-in.o
  CC      net/sunrpc/xprtsock.o
  CC      net/sunrpc/sched.o
  CC      net/sunrpc/auth.o
  CC      net/sunrpc/auth_null.o
  CC      net/sunrpc/auth_unix.o
  CC      net/wireless/wext-core.o
  CC      net/sunrpc/auth_generic.o
  CC      net/wireless/wext-proc.o
  CC      net/sunrpc/svc.o
  CC      net/wireless/wext-spy.o
  CC [M]  net/wireless/core.o
  CC      net/sunrpc/svcsock.o
  CC [M]  net/wireless/sysfs.o
  CC [M]  net/wireless/radiotap.o
  CC      net/sunrpc/svcauth.o
  CC [M]  net/wireless/util.o
  CC      net/sunrpc/svcauth_unix.o
  CC [M]  net/wireless/reg.o
  CC      net/sunrpc/addr.o
  CC      net/sunrpc/rpcb_clnt.o
  CC [M]  net/wireless/scan.o
  CC      net/sunrpc/timer.o
  CC [M]  net/wireless/nl80211.o
  CC      net/sunrpc/xdr.o
  CC      net/sunrpc/sunrpc_syms.o
  CC      net/sunrpc/cache.o
  CC      net/sunrpc/rpc_pipe.o
  CC [M]  net/wireless/mlme.o
  CC      net/sunrpc/svc_xprt.o
  CC [M]  net/wireless/ibss.o
  CC [M]  net/wireless/sme.o
  CC      net/sunrpc/stats.o
  CC [M]  net/wireless/chan.o
  CC      net/sunrpc/sysctl.o
  CC [M]  net/wireless/ethtool.o
  CC      net/sunrpc/auth_gss/auth_gss.o
  CC [M]  net/wireless/wext-compat.o
  CC      net/sunrpc/auth_gss/gss_generic_token.o
  CC [M]  net/wireless/wext-sme.o
  CC      net/sunrpc/auth_gss/gss_mech_switch.o
  CC [M]  net/wireless/lib80211.o
  CC      net/sunrpc/auth_gss/svcauth_gss.o
  LD      net/wireless/built-in.o
  LD [M]  net/wireless/cfg80211.o
  CC      net/xfrm/xfrm_policy.o
  CC      net/sunrpc/auth_gss/gss_krb5_mech.o
  CC      net/sunrpc/auth_gss/gss_krb5_seal.o
  CC      net/sunrpc/auth_gss/gss_krb5_unseal.o
  CC      net/sunrpc/auth_gss/gss_krb5_seqnum.o
  CC      net/xfrm/xfrm_state.o
  CC      net/sunrpc/auth_gss/gss_krb5_wrap.o
  CC      net/sunrpc/auth_gss/gss_krb5_crypto.o
  CC      net/sunrpc/auth_gss/gss_krb5_keys.o
  CC      net/xfrm/xfrm_hash.o
  LD      net/sunrpc/auth_gss/auth_rpcgss.o
  LD      net/sunrpc/auth_gss/rpcsec_gss_krb5.o
  LD      net/sunrpc/auth_gss/built-in.o
  LD      net/sunrpc/sunrpc.o
  LD      net/sunrpc/built-in.o
  CC      net/sysctl_net.o
  CC      net/xfrm/xfrm_input.o
  CC      net/xfrm/xfrm_output.o
  CC      net/xfrm/xfrm_algo.o
  CC      net/xfrm/xfrm_sysctl.o
  CC      net/xfrm/xfrm_user.o
  LD      net/xfrm/built-in.o
  LD      net/built-in.o
  LD      vmlinux.o
  MODPOST vmlinux.o
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
  KSYM    .tmp_kallsyms1.S
  AS      .tmp_kallsyms1.o
  LD      .tmp_vmlinux2
  KSYM    .tmp_kallsyms2.S
  AS      .tmp_kallsyms2.o
  LD      .tmp_vmlinux3
  KSYM    .tmp_kallsyms3.S
  AS      .tmp_kallsyms3.o
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready
  AS      arch/arm/boot/compressed/head.o
  Building modules, stage 2.
  GZIP    arch/arm/boot/compressed/piggy.gzip
  MODPOST 36 modules
  CC      crypto/aes_generic.mod.o
  CC      crypto/arc4.mod.o
  CC      crypto/ecb.mod.o
  CC      drivers/bluetooth/bcm203x.mod.o
  CC      drivers/bluetooth/bpa10x.mod.o
  CC      drivers/bluetooth/hci_uart.mod.o
  CC      drivers/net/wireless/libertas/libertas.mod.o
  CC      drivers/net/wireless/libertas/libertas_sdio.mod.o
  CC      drivers/net/wireless/libertas/usb8xxx.mod.o
  CC      drivers/scsi/scsi_wait_scan.mod.o
  CC      drivers/usb/gadget/g_zero.mod.o
  CC      net/bluetooth/bluetooth.mod.o
  CC      net/bluetooth/bnep/bnep.mod.o
  CC      net/bluetooth/hidp/hidp.mod.o
  CC      arch/arm/boot/compressed/misc.o
  CC      net/bluetooth/l2cap.mod.o
  CC      net/bluetooth/rfcomm/rfcomm.mod.o
  CC      net/bluetooth/sco.mod.o
  CC      arch/arm/boot/compressed/decompress.o
  CC      net/mac80211/mac80211.mod.o
  CC      net/wireless/cfg80211.mod.o
  CC      net/wireless/lib80211.mod.o
  CC      sound/core/oss/snd-mixer-oss.mod.o
  CC      sound/core/oss/snd-pcm-oss.mod.o
  CC      sound/core/snd-hwdep.mod.o
  SHIPPED arch/arm/boot/compressed/lib1funcs.S
  AS      arch/arm/boot/compressed/piggy.gzip.o
  AS      arch/arm/boot/compressed/lib1funcs.o
  LD      arch/arm/boot/compressed/vmlinux
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
  CC      sound/core/snd-page-alloc.mod.o
  CC      sound/core/snd-pcm.mod.o
  CC      sound/core/snd-rawmidi.mod.o
  CC      sound/core/snd-timer.mod.o
  CC      sound/core/snd.mod.o
  CC      sound/soc/codecs/snd-soc-twl4030.mod.o
  CC      sound/soc/omap/snd-soc-omap-mcbsp.mod.o
  CC      sound/soc/omap/snd-soc-omap.mod.o
  CC      sound/soc/omap/snd-soc-omap3pandora.mod.o
  CC      sound/soc/snd-soc-core.mod.o
  CC      sound/soundcore.mod.o
  CC      sound/usb/snd-usb-audio.mod.o
  CC      sound/usb/snd-usbmidi-lib.mod.o
  LD [M]  crypto/aes_generic.ko
  LD [M]  crypto/arc4.ko
  LD [M]  crypto/ecb.ko
  LD [M]  drivers/bluetooth/bcm203x.ko
  LD [M]  drivers/bluetooth/bpa10x.ko
  LD [M]  drivers/bluetooth/hci_uart.ko
  LD [M]  drivers/net/wireless/libertas/libertas.ko
  LD [M]  drivers/net/wireless/libertas/libertas_sdio.ko
  LD [M]  drivers/net/wireless/libertas/usb8xxx.ko
  LD [M]  drivers/scsi/scsi_wait_scan.ko
  LD [M]  drivers/usb/gadget/g_zero.ko
  LD [M]  net/bluetooth/bluetooth.ko
  LD [M]  net/bluetooth/bnep/bnep.ko
  LD [M]  net/bluetooth/hidp/hidp.ko
  LD [M]  net/bluetooth/l2cap.ko
  LD [M]  net/bluetooth/rfcomm/rfcomm.ko
  LD [M]  net/bluetooth/sco.ko
  LD [M]  net/mac80211/mac80211.ko
  LD [M]  net/wireless/cfg80211.ko
  LD [M]  net/wireless/lib80211.ko
  LD [M]  sound/core/oss/snd-mixer-oss.ko
  LD [M]  sound/core/oss/snd-pcm-oss.ko
  LD [M]  sound/core/snd-hwdep.ko
  LD [M]  sound/core/snd-page-alloc.ko
  LD [M]  sound/core/snd-pcm.ko
  LD [M]  sound/core/snd-rawmidi.ko
  LD [M]  sound/core/snd-timer.ko
  LD [M]  sound/core/snd.ko
  LD [M]  sound/soc/codecs/snd-soc-twl4030.ko
  LD [M]  sound/soc/omap/snd-soc-omap-mcbsp.ko
  LD [M]  sound/soc/omap/snd-soc-omap.ko
  LD [M]  sound/soc/omap/snd-soc-omap3pandora.ko
  LD [M]  sound/soc/snd-soc-core.ko
  LD [M]  sound/soundcore.ko
  LD [M]  sound/usb/snd-usb-audio.ko
  LD [M]  sound/usb/snd-usbmidi-lib.ko
$ 

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > > that this kind of stuff is still going on...
> > > 
> > > At least I boot test the patches I send..
> > 
> > Which is why OMAP3 and OMAP4 can't be built in mainline because they
> > spit out lots of compile errors in the OMAP code...  As they won't
> > even compile they couldn't have been boot tested.
> 
> Current mainline != the patches that Tony sent to Linus[1].
> 
> The patches that Tony sent to Linus, which Linus merged, build fine
> with omap2plus_defconfig[2].

Right, but is that sufficient testing?

Can I read into your statement that the only testing which was done was
a build of the omap2plus defconfig?  Weren't builds specific to OMAP2,
OMAP3, and OMAP4 tried?

As there is stuff like:

struct clockdomain {
        const char *name;
        union {
                const char *name;
                struct powerdomain *ptr;
        } pwrdm;
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
        const u16 clktrctrl_mask;
#endif

would you consider it's a good idea to at least run a build test with
an OMAP4-only configuration?


If it helps, here's what I do - not only do I run a few of the standard
defconfigs in the tree, but I also run a number of platform specific
builds, both covering platforms I do and do not have.  I'll pick a random
selection of existing build trees to rebuild and see what the results are.
This shows the spread of trees which I've built over the last year - and
note that many of these I don't even have:

drwxrwxr-x. 20 rmk rmk   4096 Jan 14 20:30 omap4
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:45 versatile
drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:14 iop13xx
drwxrwxr-x. 20 rmk rmk   4096 Jan 13 23:10 vexpress
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:48 integrator
drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:44 realview
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:10 assabet
drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:07 rpc
drwxrwxr-x. 21 rmk rmk   4096 Jan  7 17:34 omap3
drwxrwxr-x. 20 rmk rmk   4096 Jan  6 14:24 nommu
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:44 omap2
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:27 omap
drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:24 u300
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 19:14 pxa
drwxrwxr-x. 21 rmk rmk   4096 Jan  5 10:30 msm
drwxrwxr-x. 21 rmk rmk   4096 Jan  4 17:25 orion-kirkwood
drwxrwxr-x. 21 rmk rmk   4096 Dec 24 11:06 ks8695
drwxrwxr-x. 21 rmk rmk   4096 Dec 16 16:12 s3c2410
drwxrwxr-x. 21 rmk rmk   4096 Dec 11 17:17 ixp4xx
drwxrwxr-x. 20 rmk rmk   4096 Oct  9 22:59 netwinder2
drwxrwxr-x. 21 rmk rmk   4096 Sep  5 23:54 ebsa285
drwxrwxr-x. 21 rmk rmk   4096 Aug  4  2010 zylonite
drwxrwxr-x. 21 rmk rmk   4096 Jul  8  2010 ep93xx
drwxrwxr-x. 21 rmk rmk   4096 Jun 29  2010 corgi
drwxrwxr-x. 21 rmk rmk   4096 Apr 25  2010 ebsa110
drwxrwxr-x. 21 rmk rmk   4096 Mar 25  2010 clps711x
drwxrwxr-x. 21 rmk rmk   4096 Mar 24  2010 ixp23xx
drwxrwxr-x. 21 rmk rmk   4096 Mar 20  2010 n2100
drwxrwxr-x. 21 rmk rmk   4096 Feb 19  2010 iop32x
drwxrwxr-x. 21 rmk rmk   4096 Jan 20  2010 mx1
drwxrwxr-x. 21 rmk rmk   4096 Jan 10  2010 w90p910evb

omap4 = 4430SDP only (I have). 
omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
omap = some random omap1 config
realview = realview eb/smp only
assabet = assabet+neponset daugter board

All those are build trees, built from my git tree with:
	make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>

You can see from the above that I built a kernel for at least orion-kirkwood,
msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
none of which I have (ever) had hardware for.  I also built omap3, omap4,
and a bunch of the ARM evaluation platforms as well as older platforms
like RiscPC, but those are hidden by later re-builds for work I've been
doing since (which is all based upon commit 9e9bc97.)

I'm not saying that's perfect - it isn't.  It's better than just testing
the defconfigs - and with regular checking of kautobuild/linux-next, it
seems to catch quite a bit of really silly stuff.

Please test a (small) selection of configurations to improve build
coverage.  Try to develop a set of configurations which trip up common
issues which won't be found with the omap2plus defconfig.  Don't assume
that just because the omap2plus defconfig builds that it's ready.

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Paul Walmsley]

On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:

> On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> > On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > > > that this kind of stuff is still going on...
> > > > 
> > > > At least I boot test the patches I send..
> > > 
> > > Which is why OMAP3 and OMAP4 can't be built in mainline because they
> > > spit out lots of compile errors in the OMAP code...  As they won't
> > > even compile they couldn't have been boot tested.
> > 
> > Current mainline != the patches that Tony sent to Linus[1].
> > 
> > The patches that Tony sent to Linus, which Linus merged, build fine
> > with omap2plus_defconfig[2].
> 
> Right, but is that sufficient testing?
> 
> Can I read into your statement that the only testing which was done was
> a build of the omap2plus defconfig?

No.  The patches that Tony merged from me were built with omap1_defconfig 
and boot-tested on OMAP5912 OSK; they were built with an N8x0-specific 
configuration and boot-tested on N800; and they were built with 
omap2plus_defconfig and boot-tested on 2430SDP, OMAP3530 Beagle, DM37xx 
Beagle XM, and OMAP4430 ES2 Panda.  A brief summary of that testing was 
part of the pull request that was sent to Tony[1].

The problem in this case was that I did not compile-test them with an 
OMAP4-only configuration - hence the clockdomain and PRM breakage.

> Weren't builds specific to OMAP2, OMAP3, and OMAP4 tried?
> 
> As there is stuff like:
> 
> struct clockdomain {
>         const char *name;
>         union {
>                 const char *name;
>                 struct powerdomain *ptr;
>         } pwrdm;
> #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
>         const u16 clktrctrl_mask;
> #endif
> 
> would you consider it's a good idea to at least run a build test with
> an OMAP4-only configuration?

Yes.  Given the clockdomain and PRM breakage from this merge window, I 
plan to compile-test future branches that I send to Tony with quite a few 
non-multi-OMAP configs.  I consider it my responsibility to catch breakage 
from my branches before it makes it to Tony.

> If it helps, here's what I do - not only do I run a few of the standard
> defconfigs in the tree, but I also run a number of platform specific
> builds, both covering platforms I do and do not have.  I'll pick a random
> selection of existing build trees to rebuild and see what the results are.
> This shows the spread of trees which I've built over the last year - and
> note that many of these I don't even have:
> 
> drwxrwxr-x. 20 rmk rmk   4096 Jan 14 20:30 omap4
> drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:45 versatile
> drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:14 iop13xx
> drwxrwxr-x. 20 rmk rmk   4096 Jan 13 23:10 vexpress
> drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:48 integrator
> drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:44 realview
> drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:10 assabet
> drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:07 rpc
> drwxrwxr-x. 21 rmk rmk   4096 Jan  7 17:34 omap3
> drwxrwxr-x. 20 rmk rmk   4096 Jan  6 14:24 nommu
> drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:44 omap2
> drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:27 omap
> drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:24 u300
> drwxrwxr-x. 21 rmk rmk   4096 Jan  5 19:14 pxa
> drwxrwxr-x. 21 rmk rmk   4096 Jan  5 10:30 msm
> drwxrwxr-x. 21 rmk rmk   4096 Jan  4 17:25 orion-kirkwood
> drwxrwxr-x. 21 rmk rmk   4096 Dec 24 11:06 ks8695
> drwxrwxr-x. 21 rmk rmk   4096 Dec 16 16:12 s3c2410
> drwxrwxr-x. 21 rmk rmk   4096 Dec 11 17:17 ixp4xx
> drwxrwxr-x. 20 rmk rmk   4096 Oct  9 22:59 netwinder2
> drwxrwxr-x. 21 rmk rmk   4096 Sep  5 23:54 ebsa285
> drwxrwxr-x. 21 rmk rmk   4096 Aug  4  2010 zylonite
> drwxrwxr-x. 21 rmk rmk   4096 Jul  8  2010 ep93xx
> drwxrwxr-x. 21 rmk rmk   4096 Jun 29  2010 corgi
> drwxrwxr-x. 21 rmk rmk   4096 Apr 25  2010 ebsa110
> drwxrwxr-x. 21 rmk rmk   4096 Mar 25  2010 clps711x
> drwxrwxr-x. 21 rmk rmk   4096 Mar 24  2010 ixp23xx
> drwxrwxr-x. 21 rmk rmk   4096 Mar 20  2010 n2100
> drwxrwxr-x. 21 rmk rmk   4096 Feb 19  2010 iop32x
> drwxrwxr-x. 21 rmk rmk   4096 Jan 20  2010 mx1
> drwxrwxr-x. 21 rmk rmk   4096 Jan 10  2010 w90p910evb
> 
> omap4 = 4430SDP only (I have). 
> omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
> omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
> omap = some random omap1 config
> realview = realview eb/smp only
> assabet = assabet+neponset daugter board
> 
> All those are build trees, built from my git tree with:
> 	make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>
> 
> You can see from the above that I built a kernel for at least orion-kirkwood,
> msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
> none of which I have (ever) had hardware for.  I also built omap3, omap4,
> and a bunch of the ARM evaluation platforms as well as older platforms
> like RiscPC, but those are hidden by later re-builds for work I've been
> doing since (which is all based upon commit 9e9bc97.)
> 
> I'm not saying that's perfect - it isn't.  It's better than just testing
> the defconfigs - and with regular checking of kautobuild/linux-next, it
> seems to catch quite a bit of really silly stuff.

I agree with you.  I do think it's a good idea, and it's something that I 
plan to do for future branches that I send to Tony.


regards


- Paul


1. Walmsley, Paul. _[GIT PULL v3] OMAP: core/PM architecture: pull request 
   for 2.6.38_.  Posted to linux-omap at vger.kernel.org mailing list on 22 
   December 2010. Available from 
   http://www.mail-archive.com/linux-omap at vger.kernel.org/msg41289.html
   (among others).

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Paul Walmsley]

On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:

> If it helps, here's what I do - not only do I run a few of the standard
> defconfigs in the tree, but I also run a number of platform specific
> builds, both covering platforms I do and do not have.  I'll pick a random
> selection of existing build trees to rebuild and see what the results are.
> This shows the spread of trees which I've built over the last year - and
> note that many of these I don't even have:
> 
> drwxrwxr-x. 20 rmk rmk   4096 Jan 14 20:30 omap4
> drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:45 versatile
> drwxrwxr-x. 21 rmk rmk   4096 Jan 14 11:14 iop13xx
> drwxrwxr-x. 20 rmk rmk   4096 Jan 13 23:10 vexpress
> drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:48 integrator
> drwxrwxr-x. 21 rmk rmk   4096 Jan 11 13:44 realview
> drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:10 assabet
> drwxrwxr-x. 21 rmk rmk   4096 Jan  8 11:07 rpc
> drwxrwxr-x. 21 rmk rmk   4096 Jan  7 17:34 omap3
> drwxrwxr-x. 20 rmk rmk   4096 Jan  6 14:24 nommu
> drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:44 omap2
> drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:27 omap
> drwxrwxr-x. 21 rmk rmk   4096 Jan  6 10:24 u300
> drwxrwxr-x. 21 rmk rmk   4096 Jan  5 19:14 pxa
> drwxrwxr-x. 21 rmk rmk   4096 Jan  5 10:30 msm
> drwxrwxr-x. 21 rmk rmk   4096 Jan  4 17:25 orion-kirkwood
> drwxrwxr-x. 21 rmk rmk   4096 Dec 24 11:06 ks8695
> drwxrwxr-x. 21 rmk rmk   4096 Dec 16 16:12 s3c2410
> drwxrwxr-x. 21 rmk rmk   4096 Dec 11 17:17 ixp4xx
> drwxrwxr-x. 20 rmk rmk   4096 Oct  9 22:59 netwinder2
> drwxrwxr-x. 21 rmk rmk   4096 Sep  5 23:54 ebsa285
> drwxrwxr-x. 21 rmk rmk   4096 Aug  4  2010 zylonite
> drwxrwxr-x. 21 rmk rmk   4096 Jul  8  2010 ep93xx
> drwxrwxr-x. 21 rmk rmk   4096 Jun 29  2010 corgi
> drwxrwxr-x. 21 rmk rmk   4096 Apr 25  2010 ebsa110
> drwxrwxr-x. 21 rmk rmk   4096 Mar 25  2010 clps711x
> drwxrwxr-x. 21 rmk rmk   4096 Mar 24  2010 ixp23xx
> drwxrwxr-x. 21 rmk rmk   4096 Mar 20  2010 n2100
> drwxrwxr-x. 21 rmk rmk   4096 Feb 19  2010 iop32x
> drwxrwxr-x. 21 rmk rmk   4096 Jan 20  2010 mx1
> drwxrwxr-x. 21 rmk rmk   4096 Jan 10  2010 w90p910evb
> 
> omap4 = 4430SDP only (I have). 
> omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
> omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
> omap = some random omap1 config
> realview = realview eb/smp only
> assabet = assabet+neponset daugter board
> 
> All those are build trees, built from my git tree with:
> 	make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>
> 
> You can see from the above that I built a kernel for at least orion-kirkwood,
> msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
> none of which I have (ever) had hardware for.  I also built omap3, omap4,
> and a bunch of the ARM evaluation platforms as well as older platforms
> like RiscPC, but those are hidden by later re-builds for work I've been
> doing since (which is all based upon commit 9e9bc97.)
> 
> I'm not saying that's perfect - it isn't.  It's better than just testing
> the defconfigs - and with regular checking of kautobuild/linux-next, it
> seems to catch quite a bit of really silly stuff.

I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6 
plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your 
compile-testing regimen, if one is not already present?

That would help catch compile problems like the recent CONFIG_SWP_EMULATE 
one[1].


- Paul

1. _linux-next: omap2plus_defconfig not building_.  linux-arm-kernel
   mailing list thread, started 19 October 2010 by Anand Gadiyar.
   http://comments.gmane.org/gmane.linux.ports.arm.kernel/93694

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 04:10:29PM -0700, Paul Walmsley wrote:
> I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6 
> plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your 
> compile-testing regimen, if one is not already present?
> 
> That would help catch compile problems like the recent CONFIG_SWP_EMULATE 
> one[1].

Such as these?

../build/msm/.config:CONFIG_CPU_V6=y
../build/omap2/.config:CONFIG_CPU_V6=y
../build/omap3/.config:CONFIG_CPU_V7=y
../build/omap3/.config:# CONFIG_SWP_EMULATE is not set
../build/omap4/.config:CONFIG_CPU_V7=y
../build/omap4/.config:# CONFIG_SWP_EMULATE is not set
../build/realview/.config:CONFIG_CPU_V6=y
../build/realview/.config:CONFIG_CPU_V7=y
../build/realview/.config:CONFIG_SWP_EMULATE=y
../build/vexpress/.config:CONFIG_CPU_V7=y
../build/vexpress/.config:CONFIG_SWP_EMULATE=y

So, I already have configs for V7 only+SWP_EMULATE=y, V7 only+SWP_EMULATE=n,
V6 only, V6+V7+SWP_EMULATE=y but not V6+V7+SWP_EMULATE=n

It doesn't appear for me because my toolchain new enough to be broken.

What has been merged into the toolchain (gcc emitting a .armv7 at the
beginning of its assembler output) was a pretty stupid idea as it's
going to break _everything_ out there which has been carefully crafted
to compile for ARMv6 but selectively use ARMv7 instructions.

I am very much of the opinion that this new "feature" needs to be removed
from the toolchain, and it should do as previous versions of the toolchain
does - where the gcc frontend passes the correct architecture flags to
the assembler.

This "feature" will have broken a lot more than just the SWP emulate code
in the kernel - anything which tries to build a kernel crossing several
CPU architectures will hit this failure.

This is what I get from building the realview configuration listed above:

$ emake O=../build/realview/ arch/arm/kernel/
  Using /home/rmk/git/linux-2.6-rmk as source for kernel
  GEN     /home/rmk/git/build/realview/Makefile
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
  CALL    /home/rmk/git/linux-2.6-rmk/scripts/checksyscalls.sh
  CC      arch/arm/kernel/elf.o
  AS      arch/arm/kernel/entry-armv.o
  AS      arch/arm/kernel/entry-common.o
  CC      arch/arm/kernel/irq.o
  CC      arch/arm/kernel/process.o
  CC      arch/arm/kernel/ptrace.o
  CC      arch/arm/kernel/return_address.o
  CC      arch/arm/kernel/setup.o
  CC      arch/arm/kernel/signal.o
  CC      arch/arm/kernel/sys_arm.o
  CC      arch/arm/kernel/stacktrace.o
  CC      arch/arm/kernel/time.o
  CC      arch/arm/kernel/traps.o
  CC      arch/arm/kernel/compat.o
  CC      arch/arm/kernel/leds.o
  CC      arch/arm/kernel/armksyms.o
  CC      arch/arm/kernel/module.o
  CC      arch/arm/kernel/sched_clock.o
  CC      arch/arm/kernel/smp.o
  CC      arch/arm/kernel/smp_tlb.o
  CC      arch/arm/kernel/smp_scu.o
  CC      arch/arm/kernel/smp_twd.o
  CC      arch/arm/kernel/sys_oabi-compat.o
  CC      arch/arm/kernel/swp_emulate.o
  CC      arch/arm/kernel/hw_breakpoint.o
  CC      arch/arm/kernel/pmu.o
  CC      arch/arm/kernel/perf_event.o
  CC      arch/arm/kernel/io.o
  AS      arch/arm/kernel/debug.o
  LD      arch/arm/kernel/built-in.o
  AS      arch/arm/kernel/head.o
  CC      arch/arm/kernel/init_task.o
  LDS     arch/arm/kernel/vmlinux.lds

So, as you can see, it builds perfectly fine for me.  GCC 4.3.5,
binutils 2.19.1.  The command used to build swp_emulate.o was:

  arm-linux-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d  -nostdinc
 -isystem /usr/local/aeabi/lib/gcc/arm-linux/4.3.5/include
 -I/home/rmk/git/linux-2.6-rmk/arch/arm/include -Iinclude 
 -I/home/rmk/git/linux-2.6-rmk/include -include include/generated/autoconf.h 
 -I/home/rmk/git/linux-2.6-rmk/arch/arm/kernel -Iarch/arm/kernel
 -D__KERNEL__ -mlittle-endian  
 -I/home/rmk/git/linux-2.6-rmk/arch/arm/mach-realview/include  
 -I/home/rmk/git/linux-2.6-rmk/arch/arm/plat-versatile/include
 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
 -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
 -Wno-format-security -fno-delete-null-pointer-checks -O2 -marm
 -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux
 -mno-thumb-interwork -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s
 -msoft-float -Uarm -fno-stack-protector -fno-omit-frame-pointer
 -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign
 -fno-strict-overflow -Wa,-march=armv7-a   
 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(swp_emulate)" 
 -D"KBUILD_MODNAME=KBUILD_STR(swp_emulate)"
 -c -o arch/arm/kernel/swp_emulate.o
 /home/rmk/git/linux-2.6-rmk/arch/arm/kernel/swp_emulate.c

So, the reason I don't see it is because I don't build the omap2plus_defconfig
build, as:

# ARMv6k
config CPU_32v6K
        bool "Support ARM V6K processor extensions" if !SMP
        depends on CPU_V6 || CPU_V7
        default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)

OMAP2 prevents the selection of armv6k support.  This is probably a very
bad idea if you want to run the resulting kernel on SMP hardware as it
removes a barrier in the spinlock code and disables the SMP-safe bitops.

The original patch which started turning this off was from the MX3 stuff,
but without explaination.

However, OMAP extended this to disabling the select statement for CPU_32v6K
even if CPU_V7 is set:

 config CPU_V7
        bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K
+       select CPU_32v6K if !ARCH_OMAP2

Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
patch should not have been merged.

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> 
> # ARMv6k
> config CPU_32v6K
>         bool "Support ARM V6K processor extensions" if !SMP
>         depends on CPU_V6 || CPU_V7
>         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> 
> OMAP2 prevents the selection of armv6k support.  This is probably a very
> bad idea if you want to run the resulting kernel on SMP hardware as it
> removes a barrier in the spinlock code and disables the SMP-safe bitops.

I have some ideas to fix this. Unfortunately it will be inefficient
as spinlock.h can be included from modules too :( I was thinking we can
implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
builds.
 
> The original patch which started turning this off was from the MX3 stuff,
> but without explaination.
> 
> However, OMAP extended this to disabling the select statement for CPU_32v6K
> even if CPU_V7 is set:
> 
>  config CPU_V7
>         bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K
> +       select CPU_32v6K if !ARCH_OMAP2
> 
> Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> patch should not have been merged.

The only way we can fix that is do smp_on_up style rewriting of the assembly
during init between CPUv6 and v6K. Want me to do a patch for that?

For the defconfigs, I have a branch where I occasionally compile all
the old removed defconfigs too. And I believe Kevin test compiles various
PM options.

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > 
> > # ARMv6k
> > config CPU_32v6K
> >         bool "Support ARM V6K processor extensions" if !SMP
> >         depends on CPU_V6 || CPU_V7
> >         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > 
> > OMAP2 prevents the selection of armv6k support.  This is probably a very
> > bad idea if you want to run the resulting kernel on SMP hardware as it
> > removes a barrier in the spinlock code and disables the SMP-safe bitops.
> 
> I have some ideas to fix this. Unfortunately it will be inefficient
> as spinlock.h can be included from modules too :( I was thinking we can
> implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
> builds.

For spinlocks, the important thing is the barrier.  The wfe/sev are an
optimization.  The barrier contained with the ifdef is a valid V6
instruction.

> > The original patch which started turning this off was from the MX3 stuff,
> > but without explaination.
> > 
> > However, OMAP extended this to disabling the select statement for CPU_32v6K
> > even if CPU_V7 is set:
> > 
> >  config CPU_V7
> >         bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K
> > +       select CPU_32v6K if !ARCH_OMAP2
> > 
> > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> > patch should not have been merged.
> 
> The only way we can fix that is do smp_on_up style rewriting of the assembly
> during init between CPUv6 and v6K. Want me to do a patch for that?

The bitops code is quite different between the two versions, and I doubt
the smp_on_up rewriting will look at all pretty.  I think it needs an
alternative idea - like not using the 'byte' operations at all.

Whether we have any code which passes non-word aligned pointers to bitops
isn't particularly known - in theory they should all be unsigned long *'s,
so should be word-aligned.  Who knows what filesystems do though... and
such a change could be disasterous to peoples data if the block/inode
bitmaps get corrupted.

IOW, such a change needs testing on a box where a range of filesystems are
used, and the filesystems can be thrown away if corrupted.

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > > 
> > > # ARMv6k
> > > config CPU_32v6K
> > >         bool "Support ARM V6K processor extensions" if !SMP
> > >         depends on CPU_V6 || CPU_V7
> > >         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > > 
> > > OMAP2 prevents the selection of armv6k support.  This is probably a very
> > > bad idea if you want to run the resulting kernel on SMP hardware as it
> > > removes a barrier in the spinlock code and disables the SMP-safe bitops.
> > 
> > I have some ideas to fix this. Unfortunately it will be inefficient
> > as spinlock.h can be included from modules too :( I was thinking we can
> > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
> > builds.
> 
> For spinlocks, the important thing is the barrier.  The wfe/sev are an
> optimization.  The barrier contained with the ifdef is a valid V6
> instruction.

OK, great it's just drain WB. Then we can do the ussual iffdeffery
on it for multi-arm builds as it does not depend on the 6K extensions.
I can do a patch for this on Monday, gotta run now.
 
> > > The original patch which started turning this off was from the MX3 stuff,
> > > but without explaination.
> > > 
> > > However, OMAP extended this to disabling the select statement for CPU_32v6K
> > > even if CPU_V7 is set:
> > > 
> > >  config CPU_V7
> > >         bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K
> > > +       select CPU_32v6K if !ARCH_OMAP2
> > > 
> > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> > > patch should not have been merged.
> > 
> > The only way we can fix that is do smp_on_up style rewriting of the assembly
> > during init between CPUv6 and v6K. Want me to do a patch for that?
> 
> The bitops code is quite different between the two versions, and I doubt
> the smp_on_up rewriting will look at all pretty.  I think it needs an
> alternative idea - like not using the 'byte' operations at all.
> 
> Whether we have any code which passes non-word aligned pointers to bitops
> isn't particularly known - in theory they should all be unsigned long *'s,
> so should be word-aligned.  Who knows what filesystems do though... and
> such a change could be disasterous to peoples data if the block/inode
> bitmaps get corrupted.

Hmm, how about emulation of those instructions for non-v6K ARMv6 processors?
I guess we could do some address checking in the bitops functions too for
multi-arm builds..
 
> IOW, such a change needs testing on a box where a range of filesystems are
> used, and the filesystems can be thrown away if corrupted.

Or we could patch in the address checking first and only disable it
later if now warnings.

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Russell King - ARM Linux]

On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > > > 
> > > > # ARMv6k
> > > > config CPU_32v6K
> > > >         bool "Support ARM V6K processor extensions" if !SMP
> > > >         depends on CPU_V6 || CPU_V7
> > > >         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > > > 
> > > > OMAP2 prevents the selection of armv6k support.  This is probably a very
> > > > bad idea if you want to run the resulting kernel on SMP hardware as it
> > > > removes a barrier in the spinlock code and disables the SMP-safe bitops.
> > > 
> > > I have some ideas to fix this. Unfortunately it will be inefficient
> > > as spinlock.h can be included from modules too :( I was thinking we can
> > > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
> > > builds.
> > 
> > For spinlocks, the important thing is the barrier.  The wfe/sev are an
> > optimization.  The barrier contained with the ifdef is a valid V6
> > instruction.
> 
> OK, great it's just drain WB. Then we can do the ussual iffdeffery
> on it for multi-arm builds as it does not depend on the 6K extensions.
> I can do a patch for this on Monday, gotta run now.
>  
> > > > The original patch which started turning this off was from the MX3 stuff,
> > > > but without explaination.
> > > > 
> > > > However, OMAP extended this to disabling the select statement for CPU_32v6K
> > > > even if CPU_V7 is set:
> > > > 
> > > >  config CPU_V7
> > > >         bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K
> > > > +       select CPU_32v6K if !ARCH_OMAP2
> > > > 
> > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> > > > patch should not have been merged.
> > > 
> > > The only way we can fix that is do smp_on_up style rewriting of the assembly
> > > during init between CPUv6 and v6K. Want me to do a patch for that?
> > 
> > The bitops code is quite different between the two versions, and I doubt
> > the smp_on_up rewriting will look at all pretty.  I think it needs an
> > alternative idea - like not using the 'byte' operations at all.
> > 
> > Whether we have any code which passes non-word aligned pointers to bitops
> > isn't particularly known - in theory they should all be unsigned long *'s,
> > so should be word-aligned.  Who knows what filesystems do though... and
> > such a change could be disasterous to peoples data if the block/inode
> > bitmaps get corrupted.
> 
> Hmm, how about emulation of those instructions for non-v6K ARMv6 processors?
> I guess we could do some address checking in the bitops functions too for
> multi-arm builds..
>  
> > IOW, such a change needs testing on a box where a range of filesystems are
> > used, and the filesystems can be thrown away if corrupted.
> 
> Or we could patch in the address checking first and only disable it
> later if now warnings.

Right, this is what I'm going to do - and it's going to *intentionally*
break omap2plus_defconfig.  Please see the commit comments for the
reason why.  We need to address the V6 issue properly without risking
users data.

To Sascha: this replaces the previous patch which I asked for your ack.

8<-----------
Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection

CPU_32v6K controls whether we use the ARMv6K extension instructions in
the kernel, and in some places whether we use SMP-safe code sequences
(eg, bitops.)

Having this configuration option disabled on a SMP supporting kernel
results in a problem: the SMP-unsafe code sequences will be used, and
as such the resulting kernel is not SMP safe.

As the atomic bitops are used by filesystems (eg, ext2 - to manipulate
the inode and block bitmaps) not having the SMP safe code sequences is
fatal for filesystem data integrity.  So running an SMP kernel without
CPU_32v6K set is dangerous.

MX3 prevents the selection of this option to ensure that it is not
enabled for their CPU, which is ARMv6 only.  MX3 folk need to ensure
that their kernel is properly configured.

OMAP prevents the selection of this option in an attempt to produce a
kernel which runs on architectures from ARMv6 to ARMv7 MPCore.

Balancing between oopsing on boot and filesystem corruption, it is far
more preferable to oops on boot until the code sequences are sorted out
properly.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 49db8b3..d61af9c 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -405,7 +405,7 @@ config CPU_V6
 config CPU_32v6K
 	bool "Support ARM V6K processor extensions" if !SMP
 	depends on CPU_V6 || CPU_V7
-	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
+	default y if SMP
 	help
 	  Say Y here if your ARMv6 processor supports the 'K' extension.
 	  This enables the kernel to use some instructions not present
-- 
1.6.2.5

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Sascha Hauer]

On Sat, Jan 15, 2011 at 05:04:55PM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> > > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > > > > 
> > > > > # ARMv6k
> > > > > config CPU_32v6K
> > > > >         bool "Support ARM V6K processor extensions" if !SMP
> > > > >         depends on CPU_V6 || CPU_V7
> > > > >         default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > > > > 
> > > > > OMAP2 prevents the selection of armv6k support.  This is probably a very
> > > > > bad idea if you want to run the resulting kernel on SMP hardware as it
> > > > > removes a barrier in the spinlock code and disables the SMP-safe bitops.
> > > > 
> > > > I have some ideas to fix this. Unfortunately it will be inefficient
> > > > as spinlock.h can be included from modules too :( I was thinking we can
> > > > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
> > > > builds.
> > > 
> > > For spinlocks, the important thing is the barrier.  The wfe/sev are an
> > > optimization.  The barrier contained with the ifdef is a valid V6
> > > instruction.
> > 
> > OK, great it's just drain WB. Then we can do the ussual iffdeffery
> > on it for multi-arm builds as it does not depend on the 6K extensions.
> > I can do a patch for this on Monday, gotta run now.
> >  
> > > > > The original patch which started turning this off was from the MX3 stuff,
> > > > > but without explaination.
> > > > > 
> > > > > However, OMAP extended this to disabling the select statement for CPU_32v6K
> > > > > even if CPU_V7 is set:
> > > > > 
> > > > >  config CPU_V7
> > > > >         bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |-       select CPU_32v6K
> > > > > +       select CPU_32v6K if !ARCH_OMAP2
> > > > > 
> > > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> > > > > patch should not have been merged.
> > > > 
> > > > The only way we can fix that is do smp_on_up style rewriting of the assembly
> > > > during init between CPUv6 and v6K. Want me to do a patch for that?
> > > 
> > > The bitops code is quite different between the two versions, and I doubt
> > > the smp_on_up rewriting will look at all pretty.  I think it needs an
> > > alternative idea - like not using the 'byte' operations at all.
> > > 
> > > Whether we have any code which passes non-word aligned pointers to bitops
> > > isn't particularly known - in theory they should all be unsigned long *'s,
> > > so should be word-aligned.  Who knows what filesystems do though... and
> > > such a change could be disasterous to peoples data if the block/inode
> > > bitmaps get corrupted.
> > 
> > Hmm, how about emulation of those instructions for non-v6K ARMv6 processors?
> > I guess we could do some address checking in the bitops functions too for
> > multi-arm builds..
> >  
> > > IOW, such a change needs testing on a box where a range of filesystems are
> > > used, and the filesystems can be thrown away if corrupted.
> > 
> > Or we could patch in the address checking first and only disable it
> > later if now warnings.
> 
> Right, this is what I'm going to do - and it's going to *intentionally*
> break omap2plus_defconfig.  Please see the commit comments for the
> reason why.  We need to address the V6 issue properly without risking
> users data.
> 
> To Sascha: this replaces the previous patch which I asked for your ack.

Ack for this one aswell:

Acked-by: Sascha Hauer <s.hauer@pengutronix.de>

> 
> 8<-----------
> Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection
> 
> CPU_32v6K controls whether we use the ARMv6K extension instructions in
> the kernel, and in some places whether we use SMP-safe code sequences
> (eg, bitops.)
> 
> Having this configuration option disabled on a SMP supporting kernel
> results in a problem: the SMP-unsafe code sequences will be used, and
> as such the resulting kernel is not SMP safe.
> 
> As the atomic bitops are used by filesystems (eg, ext2 - to manipulate
> the inode and block bitmaps) not having the SMP safe code sequences is
> fatal for filesystem data integrity.  So running an SMP kernel without
> CPU_32v6K set is dangerous.
> 
> MX3 prevents the selection of this option to ensure that it is not
> enabled for their CPU, which is ARMv6 only.  MX3 folk need to ensure
> that their kernel is properly configured.
> 
> OMAP prevents the selection of this option in an attempt to produce a
> kernel which runs on architectures from ARMv6 to ARMv7 MPCore.
> 
> Balancing between oopsing on boot and filesystem corruption, it is far
> more preferable to oops on boot until the code sequences are sorted out
> properly.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/mm/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 49db8b3..d61af9c 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -405,7 +405,7 @@ config CPU_V6
>  config CPU_32v6K
>  	bool "Support ARM V6K processor extensions" if !SMP
>  	depends on CPU_V6 || CPU_V7
> -	default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> +	default y if SMP
>  	help
>  	  Say Y here if your ARMv6 processor supports the 'K' extension.
>  	  This enables the kernel to use some instructions not present
> -- 
> 1.6.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Anand Gadiyar]

Tony Lindgren wrote:

> Here's one more es1.0 fix after the recent USB changes.
>
> Regards,
>
> Tony
>
>
> Author: Tony Lindgren <tony@atomide.com>
> Date:   Tue Jan 11 15:03:03 2011 -0800
>
>     omap4: Fix ULPI PHY init for ES1.0 SDP
>
>     Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
>     enable the ehci port on 4430SDP) added code to enable EHCI
>     support on 4430sdp board.
>
>     Looks like the ULPI pin does not seem to be muxed properly on ES1.0
>     SDP and this causes the system to reboot when the ULPI PHY is
>     enabled.
>
>     Fix this by muxing the pin, this is the same setting for
>     both ES1.0 and ES2.0. Also add checking for gpio_request.
>
>     Cc: Keshava Munegowda <keshava_mgowda@ti.com
>     Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
>
>  #ifdef CONFIG_OMAP_MUX
>  static struct omap_board_mux board_mux[] __initdata = {
> +	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
>  	{ .reg_offset = OMAP_MUX_TERMINATOR },
>  };
>  #else

Tony,

I believe this fix is fixing your reboot issue, but it's breaking
EHCI support on the SDP.

The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
By changing

The patch snippet below fixes EHCI on the SDP, but I believe that
making this change will reintroduce the "board reboots" issue
you originally reported. Could you check and tell me if this
is the case?

Just curious - is your board a Blaze, or an SDP?

diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 07d1b20..ab9fb4d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -554,7 +554,7 @@ static void __init omap_sfh7741prox_init(void)

 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
-	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> 
> I believe this fix is fixing your reboot issue, but it's breaking
> EHCI support on the SDP.
> 
> The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
> By changing
> 
> The patch snippet below fixes EHCI on the SDP, but I believe that
> making this change will reintroduce the "board reboots" issue
> you originally reported. Could you check and tell me if this
> is the case?

Hmm sorry looks like I made a typo there. That should be fixed.
 
> Just curious - is your board a Blaze, or an SDP?

It's a ES1.0 blaze, with the patch below it reboots early
during the boot. I also have to disable omap_l2_cache_init
on this board to get it to boot.
 
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 07d1b20..ab9fb4d 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -554,7 +554,7 @@ static void __init omap_sfh7741prox_init(void)
> 
>  #ifdef CONFIG_OMAP_MUX
>  static struct omap_board_mux board_mux[] __initdata = {
> -	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
> +	OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
>  	{ .reg_offset = OMAP_MUX_TERMINATOR },
>  };
>  #else

Maybe there should be a check for ES1.0 for the USB also?

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Wednesday, February 02, 2011 6:40 AM
> To: Anand Gadiyar
> Cc: Russell King - ARM Linux; linux-arm-kernel at lists.infradead.org;
> linux-omap at vger.kernel.org; Keshava Munegowda; Santosh Shilimkar;
> Felipe Balbi
> Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> >
> > I believe this fix is fixing your reboot issue, but it's breaking
> > EHCI support on the SDP.
> >
> > The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
> > By changing
> >
> > The patch snippet below fixes EHCI on the SDP, but I believe that
> > making this change will reintroduce the "board reboots" issue
> > you originally reported. Could you check and tell me if this
> > is the case?
>
> Hmm sorry looks like I made a typo there. That should be fixed.
>
> > Just curious - is your board a Blaze, or an SDP?
>
> It's a ES1.0 blaze, with the patch below it reboots early
> during the boot. I also have to disable omap_l2_cache_init
> on this board to get it to boot.
>
Do you still get this problem with 'omap_l2_cache_init' ?
As reported earlier, we don't see this issue on ES1.0
SDP.

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> >
> > It's a ES1.0 blaze, with the patch below it reboots early
> > during the boot. I also have to disable omap_l2_cache_init
> > on this board to get it to boot.
> >
> Do you still get this problem with 'omap_l2_cache_init' ?
> As reported earlier, we don't see this issue on ES1.0
> SDP.

Yeah I do, it rarely makes it to the userspace. Works reliably
if I disable omap_l2_cache_init.

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Thursday, February 03, 2011 1:19 AM
> To: Santosh Shilimkar
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > >
> > > It's a ES1.0 blaze, with the patch below it reboots early
> > > during the boot. I also have to disable omap_l2_cache_init
> > > on this board to get it to boot.
> > >
> > Do you still get this problem with 'omap_l2_cache_init' ?
> > As reported earlier, we don't see this issue on ES1.0
> > SDP.
>
> Yeah I do, it rarely makes it to the userspace. Works reliably
> if I disable omap_l2_cache_init.
>
Ok. I shall try few experiments and try to reproduce it

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

Tony,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Thursday, February 03, 2011 2:13 PM
> To: Tony Lindgren
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony at atomide.com]
> > Sent: Thursday, February 03, 2011 1:19 AM
> > To: Santosh Shilimkar
> > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> > Munegowda; Felipe Balbi
> > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > 4430SDP boot failure)
> >
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > >
> > > > It's a ES1.0 blaze, with the patch below it reboots early
> > > > during the boot. I also have to disable omap_l2_cache_init
> > > > on this board to get it to boot.
> > > >
> > > Do you still get this problem with 'omap_l2_cache_init' ?
> > > As reported earlier, we don't see this issue on ES1.0
> > > SDP.
> >
> > Yeah I do, it rarely makes it to the userspace. Works reliably
> > if I disable omap_l2_cache_init.
> >
> Ok. I shall try few experiments and try to reproduce it

Not sure if it's the same issue but I managed to reproduce the
issue on ES2.0 itself. And after some experiments, it boiled
down to the V6 and V7 issue. By disabling OMAP2 from the build,
everything was fine again.

Regards,
Santosh

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110212 00:45]:
> Tony,
> > -----Original Message-----
> > From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> > Sent: Thursday, February 03, 2011 2:13 PM
> > To: Tony Lindgren
> > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> > Munegowda; Felipe Balbi
> > Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > 4430SDP boot failure)
> >
> > > -----Original Message-----
> > > From: Tony Lindgren [mailto:tony at atomide.com]
> > > Sent: Thursday, February 03, 2011 1:19 AM
> > > To: Santosh Shilimkar
> > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > > kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> > > Munegowda; Felipe Balbi
> > > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > > 4430SDP boot failure)
> > >
> > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > > >
> > > > > It's a ES1.0 blaze, with the patch below it reboots early
> > > > > during the boot. I also have to disable omap_l2_cache_init
> > > > > on this board to get it to boot.
> > > > >
> > > > Do you still get this problem with 'omap_l2_cache_init' ?
> > > > As reported earlier, we don't see this issue on ES1.0
> > > > SDP.
> > >
> > > Yeah I do, it rarely makes it to the userspace. Works reliably
> > > if I disable omap_l2_cache_init.
> > >
> > Ok. I shall try few experiments and try to reproduce it
> 
> Not sure if it's the same issue but I managed to reproduce the
> issue on ES2.0 itself. And after some experiments, it boiled
> down to the V6 and V7 issue. By disabling OMAP2 from the build,
> everything was fine again.

Was this with linux-omap master branch or mainline?

The V6 vs V7 issues should be sorted out with Russell's patches that
we also have now in linux-omap master branch.

Regards,

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Thursday, February 24, 2011 11:09 PM
> To: Santosh Shilimkar
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110212 00:45]:
> > Tony,
> > > -----Original Message-----
> > > From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> > > Sent: Thursday, February 03, 2011 2:13 PM
> > > To: Tony Lindgren
> > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > > kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> > > Munegowda; Felipe Balbi
> > > Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > > 4430SDP boot failure)
> > >
> > > > -----Original Message-----
> > > > From: Tony Lindgren [mailto:tony at atomide.com]
> > > > Sent: Thursday, February 03, 2011 1:19 AM
> > > > To: Santosh Shilimkar
> > > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > > > kernel at lists.infradead.org; linux-omap at vger.kernel.org;
> Keshava
> > > > Munegowda; Felipe Balbi
> > > > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP
> (Re:
> > > > 4430SDP boot failure)
> > > >
> > > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > > > >
> > > > > > It's a ES1.0 blaze, with the patch below it reboots early
> > > > > > during the boot. I also have to disable omap_l2_cache_init
> > > > > > on this board to get it to boot.
> > > > > >
> > > > > Do you still get this problem with 'omap_l2_cache_init' ?
> > > > > As reported earlier, we don't see this issue on ES1.0
> > > > > SDP.
> > > >
> > > > Yeah I do, it rarely makes it to the userspace. Works reliably
> > > > if I disable omap_l2_cache_init.
> > > >
> > > Ok. I shall try few experiments and try to reproduce it
> >
> > Not sure if it's the same issue but I managed to reproduce the
> > issue on ES2.0 itself. And after some experiments, it boiled
> > down to the V6 and V7 issue. By disabling OMAP2 from the build,
> > everything was fine again.
>
> Was this with linux-omap master branch or mainline?
>
> The V6 vs V7 issues should be sorted out with Russell's patches that
> we also have now in linux-omap master branch.
>
This was with mainline.
Then I applied RMK's series and things were OK.

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110224 21:31]:
> >
> > Was this with linux-omap master branch or mainline?
> >
> > The V6 vs V7 issues should be sorted out with Russell's patches that
> > we also have now in linux-omap master branch.
> >
> This was with mainline.
> Then I applied RMK's series and things were OK.

OK good to hear & thanks for checking that.

Tony

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Anand Gadiyar]

Tony Lindgren wrote:
> * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> >
> > I believe this fix is fixing your reboot issue, but it's breaking
> > EHCI support on the SDP.
> >
> > The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
> > By changing
> >
> > The patch snippet below fixes EHCI on the SDP, but I believe that
> > making this change will reintroduce the "board reboots" issue
> > you originally reported. Could you check and tell me if this
> > is the case?
>
> Hmm sorry looks like I made a typo there. That should be fixed.
>
> > Just curious - is your board a Blaze, or an SDP?
>
> It's a ES1.0 blaze, with the patch below it reboots early
> during the boot. I also have to disable omap_l2_cache_init
> on this board to get it to boot.
>

...

> Maybe there should be a check for ES1.0 for the USB also?

Looks like a bug on the Blaze boards. There's a large capacitor
on the rails that starts charging when we try to power the USB PHY.
The inrush current is quite high and this causes the reboot.

The capacitor is on the big motherboard called the application
board, so it's independent of the silicon rev. I'm not sure
which revs are affected - I'll try and find out more about the
issue to see if I can come up with a better fix.


- Anand

[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)

[Tony Lindgren]

* Anand Gadiyar <gadiyar@ti.com> [110202 10:51]:
> Tony Lindgren wrote:
> > * Anand Gadiyar <gadiyar@ti.com> [110201 04:54]:
> > >
> > > I believe this fix is fixing your reboot issue, but it's breaking
> > > EHCI support on the SDP.
> > >
> > > The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
> > > By changing
> > >
> > > The patch snippet below fixes EHCI on the SDP, but I believe that
> > > making this change will reintroduce the "board reboots" issue
> > > you originally reported. Could you check and tell me if this
> > > is the case?
> >
> > Hmm sorry looks like I made a typo there. That should be fixed.
> >
> > > Just curious - is your board a Blaze, or an SDP?
> >
> > It's a ES1.0 blaze, with the patch below it reboots early
> > during the boot. I also have to disable omap_l2_cache_init
> > on this board to get it to boot.
> >
> 
> ...
> 
> > Maybe there should be a check for ES1.0 for the USB also?
> 
> Looks like a bug on the Blaze boards. There's a large capacitor
> on the rails that starts charging when we try to power the USB PHY.
> The inrush current is quite high and this causes the reboot.
> 
> The capacitor is on the big motherboard called the application
> board, so it's independent of the silicon rev. I'm not sure
> which revs are affected - I'll try and find out more about the
> issue to see if I can come up with a better fix.

OK thanks.

Tony