From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Walmsley Subject: Re: OMAP3EVM not booting on l-o master Date: Fri, 6 Apr 2012 12:08:32 -0600 (MDT) Message-ID: References: <20120405171653.GD3785@atomide.com> <20120406174129.GA15734@atomide.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: Received: from utopia.booyaka.com ([72.9.107.138]:59508 "EHLO utopia.booyaka.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753887Ab2DFSId (ORCPT ); Fri, 6 Apr 2012 14:08:33 -0400 In-Reply-To: <20120406174129.GA15734@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: "Mohammed, Afzal" , "R, Govindraj" , khilman@ti.com, "linux-omap@vger.kernel.org" cc Kevin On Fri, 6 Apr 2012, Tony Lindgren wrote: > So something in Paul's series is changing the interrupt > behaviour somehow? Am wondering if this might be due to the kernel not clearing some bootloader mux settings? Perhaps the bootloader is configuring the mux hardware for I/O wakeups on a pad, but the kernel is missing an mux IRQ handler or mapping for it. Or maybe one of the kernel mux entries is missing the OMAP_WAKEUP_EN or OMAP_DEVICE_PAD_WAKEUP flags for a pad that the bootloader is configuring - I seem to recall that Kevin found some problems here with the mach-omap2/serial.c mux code. Anyway, will create a patch to add some debugging here for Afzal to try. Also,it seems to me that when the mux layer starts, the code should probably clear out all of the I/O wakeup configuration in the hardware that the bootloader set up. - Paul