ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
Subsystems (4)
Paul Walmsley
maintainerPATCH 1/1 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. 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.
Based on Mark's original patch. We're removing the omap_device-based pm_lats code, so a different approach was needed.
---
Applies after the WFI cleanup series -- intended for a post-cleanup fixes pull request or a new feature pull request.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +7 -1
@@ -3439,7 +3439,13 @@ static struct omap_hwmod_class am35xx_mdio_class = {static struct omap_hwmod am35xx_mdio_hwmod = { .name ="davinci_mdio" , .class = &am35xx_mdio_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 ), };/*
Signature · 1 line
1.7.10.4
Paul Walmsley
maintainerPATCH 1/1 ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
Quoted 2 lines · Paul Walmsley
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 <[email protected]>
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.
--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +7 -1
@@ -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 */
Signature · 1 line
1.7.10.4
PATCH 1/1 ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
Quoted 1 line · Paul Walmsley
On Sun, 30 Dec 2012, Paul Walmsley wrote:
Hi Paul.
Quoted 41 lines
Quoted 2 lines
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 <[email protected]>
Date: Sun, 30 Dec 2012 10:36:36 -0700
Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC activeAccording 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.htmlFurther 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_WFIflag.Based on Mark's original patch. We're removing the omap_device-based
pm_latscode, so a different approach was needed.This second version contains some corrections thanks to Mark's review.
Signed-off-by Paul Walmsley <[email protected]>Cc Mark A. Greer <[email protected]>--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +0
-0@@ -3493,7 +3493,13 @@ static struct omap_hwmod am35xx_emac_hwmod = { .name = "davinci_emac", .mpu_irqs = am35xx_emac_mpu_irqs,
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c static struct omap_hwmod am35xx_emac_hwmod = { · line 3503
Quoted 10 lines
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +7
-1.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), };
Sorry to nag but I think the comment needs to be updated to remove the sentence about the missing EMAC hwmod.
Mark
--
Paul Walmsley
maintainerPATCH 1/1 ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
Hi Mark
Quoted 2 lines · Mark A. Greer
Sorry to nag but I think the comment needs to be updated to remove the sentence about the missing EMAC hwmod.
You are absolutely right, and the correction is very much appreciated. Updated patch follows.
- Paul
From: Paul Walmsley <[email protected]>
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 third version contains some corrections thanks to Mark's review.
--- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +6 -1
@@ -3493,7 +3493,12 @@ 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. +* http://www.spinics.net/lists/arm-kernel/msg174734.html +*/ + .flags = (HWMOD_NO_IDLEST | HWMOD_BLOCK_WFI), };/* l3_core -> davinci emac interface */
Signature · 1 line
1.7.10.4
PATCH 1/1 ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
Quoted 26 lines · Paul Walmsley
Hi Mark
Quoted 2 lines · Mark A. Greer
Sorry to nag but I think the comment needs to be updated to remove the sentence about the missing EMAC hwmod.
You are absolutely right, and the correction is very much appreciated. Updated patch follows.
- Paul
From: Paul Walmsley <[email protected]>
Date: Sun, 30 Dec 2012 10:36:36 -0700
Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC activeAccording 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.htmlFurther 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_WFIflag.
Quoted 8 lines
Based on Mark's original patch. We're removing the omap_device-based
pm_latscode, so a different approach was needed.This third version contains some corrections thanks to Mark's review.
Signed-off-by Paul Walmsley <[email protected]>Cc Mark A. Greer <[email protected]>---
FWIW,