From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: OMAP34xx Date: Tue, 07 Feb 2012 16:53:56 -0800 Message-ID: <87y5sei1qz.fsf@ti.com> References: <20120204185453.GB17309@n2100.arm.linux.org.uk> <20120204190109.GL20333@atomide.com> <20120204203453.GD17309@n2100.arm.linux.org.uk> <20120205012556.GG1426@atomide.com> <20120205125904.GB11372@n2100.arm.linux.org.uk> <20120205172925.GS20333@atomide.com> <20120205175809.GF17309@n2100.arm.linux.org.uk> <20120205182910.GK1426@atomide.com> <87lioegtk9.fsf@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog107.obsmtp.com ([74.125.149.197]:39424 "EHLO na3sys009aog107.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756509Ab2BHAx7 (ORCPT ); Tue, 7 Feb 2012 19:53:59 -0500 Received: by mail-pw0-f43.google.com with SMTP id s6so139011pbd.16 for ; Tue, 07 Feb 2012 16:53:59 -0800 (PST) In-Reply-To: <87lioegtk9.fsf@ti.com> (Kevin Hilman's message of "Tue, 07 Feb 2012 14:36:06 -0800") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: Russell King - ARM Linux , linux-omap@vger.kernel.org, Arnd Bergmann , Olof Johansson Kevin Hilman writes: > Tony Lindgren writes: > > [...] > >>> > > --- a/arch/arm/mach-omap2/pm34xx.c >>> > > +++ b/arch/arm/mach-omap2/pm34xx.c >>> > > @@ -420,7 +420,7 @@ static void omap3_pm_idle(void) >>> > > { >>> > > local_fiq_disable(); >>> > > >>> > > - if (omap_irq_pending()) >>> > > + if (omap_irq_pending() || 1) >>> > > goto out; >>> > > >>> > > trace_power_start(POWER_CSTATE, 1, smp_processor_id()); >>> > >>> > This does not look right to me. I thought reverting of the serial >>> > patches should have already solved the issue you're seeing with >>> > slow serial port? >>> > >>> > Those are the reverting commits drivers/tty/serial/serial-omap.c: >>> > >>> > 8a74e9ffd97dc9de063de8c02ae32db79dd60436 (Revert "tty: serial: OMAP: ensure >>> > FIFO levels are set correctly in non-DMA mode") >>> > >>> > af681cad3f79ad8f7bd6cb170b70990aeef74233 (Revert "tty: serial: OMAP: transmit >>> > FIFO threshold interrupts don't wake the chip") >>> >>> These commits have absolutely nothing to do with it. I pointed out the >>> bad commit in one of my emails: >>> >>> commit 2fd149645eb46d26130d7070c6de037dddf34880 >>> Author: Govindraj.R >>> Date: Wed Nov 9 17:41:21 2011 +0530 >>> >>> ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos >>> >>> Omap_uart_can_sleep function blocks system wide low power state until >>> uart is active remove this func and add qos requests to prevent >>> MPU from transitioning. >>> >>> Keep qos request to default value which will allow MPU to transition >>> and while uart baud rate is available calculate the latency value >>> from the baudrate and use the same to hold constraint while uart clocks >>> are enabled, and if uart is auto-idled the constraint is updated with >>> default constraint value allowing MPU to transition. >>> >>> Qos requests are blocking notifier calls so put these requests to >>> work queue, also the driver uses irq_safe version of runtime API's >>> and callbacks can be called in interrupt disabled context. >>> So to avoid warn on slow path warning while using qos update >>> API's from runtime callbacks use the qos_work_queue. >>> >>> During bootup the runtime_resume call backs might not be called and runtime >>> callback gets called only after uart is idled by setting the autosuspend >>> timeout. So qos_request from runtime resume callback might not activated during >>> boot if uart baudrate is calculated during bootup for console uart, so schedule >>> the qos_work queue once we calc_latency while configuring the uart port. >>> >>> Flush and complete any pending qos jobs in work queue while suspending. >>> >>> Signed-off-by: Govindraj.R >>> Acked-by: Greg Kroah-Hartman (for drivers/tty changes) >>> Signed-off-by: Kevin Hilman >>> >>> Basically, it looks like the OMAP 3 UART is not delivering transmit IRQs >>> while in some of the deeper low power modes. >>> >>> I tried reverting the rest of the patches between this one and HEAD for >>> omap-serial.c, but they have no effect what so ever on this bug. As I >>> said in one of my emails in this thread, the above commit can't be >>> trivially reverted because some other stuff that the code relied upon >>> has vanished. >>> >>> So, the above along with the other part in arch/arm/mach-omap2/cpuidle34xx.c >>> is the smallest 'fix' I could find if resolving the regression. >> >> OK, thanks, that should be enough info for let Kevin take a look at this. > > This one is indeed strange. I have not seen this on the 34xx devices > I'm using (3430/n900, 3530/Overo, 3630/Zoom3). OK, I've reproduced this on v3.3-rc2. The reason I wasn't seeing this is because I'm using the fixes Paul has already posted that fix this problem: http://marc.info/?l=linux-arm-kernel&m=132754676814391&w=2 Kevin