From patchwork Tue Jan 8 19:21:16 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Walmsley X-Patchwork-Id: 1947971 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id C1ED23FED4 for ; Tue, 8 Jan 2013 19:21:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757069Ab3AHTVR (ORCPT ); Tue, 8 Jan 2013 14:21:17 -0500 Received: from utopia.booyaka.com ([74.50.51.50]:58034 "EHLO utopia.booyaka.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757047Ab3AHTVR (ORCPT ); Tue, 8 Jan 2013 14:21:17 -0500 Received: (qmail 11264 invoked by uid 1019); 8 Jan 2013 19:21:16 -0000 Date: Tue, 8 Jan 2013 19:21:16 +0000 (UTC) From: Paul Walmsley To: linux-omap@vger.kernel.org cc: linux-arm-kernel@lists.infradead.org, mgreer@animalcreek.com Subject: Re: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Sun, 30 Dec 2012, Paul Walmsley wrote: > However, for some reason, we don't have an EMAC hwmod -- probably some > bug in the data -- so set the flag on the MDIO hwmod data instead. Mark and I discussed this in private E-mail. Looks like I managed to confuse AM33xx and AM3517 :-( Here's the updated patch. - Paul From: Paul Walmsley Date: Sun, 30 Dec 2012 10:36:36 -0700 Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable to wake the ARM up from WFI: http://www.spinics.net/lists/arm-kernel/msg174734.html Further troubleshooting was unable to narrow the problem down. So we don't have much choice other than to block WFI when the EMAC is active with the HWMOD_BLOCK_WFI flag. Based on Mark's original patch. We're removing the omap_device-based pm_lats code, so a different approach was needed. This second version contains some corrections thanks to Mark's review. Signed-off-by: Paul Walmsley Cc: Mark A. Greer --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index 8bb2628..7af28b7 100644 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -3493,7 +3493,13 @@ static struct omap_hwmod am35xx_emac_hwmod = { .name = "davinci_emac", .mpu_irqs = am35xx_emac_mpu_irqs, .class = &am35xx_emac_class, - .flags = HWMOD_NO_IDLEST, + /* + * According to Mark Greer, the MPU will not return from WFI + * when the EMAC signals an interrupt. We're missing an EMAC + * hwmod for some reason, so add the flag to the MDIO instead. + * http://www.spinics.net/lists/arm-kernel/msg174734.html + */ + .flags = (HWMOD_NO_IDLEST | HWMOD_BLOCK_WFI), }; /* l3_core -> davinci emac interface */