From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: beagle hangs in uart3 disabling clocks Date: Tue, 05 Oct 2010 10:33:32 -0700 Message-ID: <87hbh0sfwz.fsf@deeprootsystems.com> References: <4CA9C5F6.7060902@ti.com> <87wrpy0xp3.fsf@deeprootsystems.com> <87iq1hzt3u.fsf@deeprootsystems.com> <4CAACFFF.9040702@ti.com> <4CAAF126.5080206@ti.com> <4CAAF6B4.4030708@ti.com> <4CAB077F.5020806@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pv0-f174.google.com ([74.125.83.174]:58768 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754677Ab0JERdf (ORCPT ); Tue, 5 Oct 2010 13:33:35 -0400 Received: by pvg2 with SMTP id 2so1710125pvg.19 for ; Tue, 05 Oct 2010 10:33:34 -0700 (PDT) In-Reply-To: (Paul Walmsley's message of "Tue, 5 Oct 2010 11:26:19 -0600 (MDT)") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Paul Walmsley Cc: Pramod , Ming Lei , Govindraj , "Premi, Sanjeev" , "linux-omap@vger.kernel.org" , "Govindraj R." Paul Walmsley writes: > On Tue, 5 Oct 2010, Pramod wrote: > >> On Tuesday 05 October 2010 03:33 PM, Paul Walmsley wrote: >> > >> > Looks to me like it boots fine. If you had hwmod debugging enabled, your >> > kernel should have crashed after >> > >> > omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 >> > omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 >> > omap-hsuart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 >> > >> > ... but it didn't crash there. I'm not seeing any hwmod debug messages >> > though, so you probably don't have DEBUG defined in omap_hwmod.c. >> > >> > So, I suspect whatever problem you're seeing is unrelated to the problem >> > that the patch was intended to solve. >> > >> > >> > - Paul >> >> The hwmod debug messages will be seen when I enable them on the go with: >> echo -n 'file omap_hwmod.c +p' > /debug/dynamic_debug/control >> >> This will show lots of logs as below ending with UART3 clock disabling and a >> hang. >> >> omap_hwmod:omap_hwmod: uart1: idling >> omap_hwmod:omap_hwmod: uart1: disabling clocks >> omap_hwmod:omap_hwmod: uart2: idling >> omap_hwmod:omap_hwmod: uart2: disabling clocks >> omap_hwmod:omap_hwmod: uart1: enabling >> omap_hwmod:omap_hwmod: uart1: enabling clocks >> omap_hwmod:omap_hwmod: uart2: enabling >> omap_hwmod:omap_hwmod: uart2: enabling clocks >> omap_hwmod:omap_hwmod: uart3: idling >> omap_hwmod:omap_hwmod: uart3: disabling clock > > OK, the problem here is probably with the real serial console generating > messages while the hwmod is idle, not earlyconsole/bootconsole. The patch > could be extended to fix that, but it doesn't address that right now. Why > don't you take a shot at doing that? > > In this context, the real serial console is only part of the problem. > For a complete fix, I suspect that one would have to tinker with the OMAP > UART driver or serial core, since other drivers beyond the real console > may be using the serial port (e.g. Bluetooth). > > Also, thinking about this issue further, there needs to be an additional > fix at least in omap_serial_init_port() to ensure that the UART TX FIFO is > completely drained before it starts messing around with the underlying > hwmod. Similarly, whenever the PM runtime conversion is done for > drivers/serial/omap-serial.c, it will need to ensure that the TX FIFO has > drained before going to idle. Now that the base omap-serial driver is queued for mainline, the next step is to move all the PM hackery from mach-omap2/serial.c into the driver itself by using the runtime PM API. This should ensure that any users of the real serial driver will have an active UART. Kevin