* Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> [140828 12:37]:
> On 08/28/2014 06:46 PM, Tony Lindgren wrote:
> >
> > Sounds like there should be some way to clear that state.. I wonder
> > if omap-serial.c had something before it's DMA support was removed?
>
> Its DMA was removed? Like there was DMA support?
Yeah see commit 494574304711a333386e7dd5fd3ebbc3b7024994...
> > I'd assume when the UART is powered down by runtime PM it's state
> > is completetely reset and we could restore the non-DMA state?
>
> I tried that by canceling the RX-DMA request and removing the DMA-enable
> bits from UART but it didn't help. Then I noticed that once that DMA en
> bit is set, the UART won't do any idle.
>
> > Maybe post your current patches and a test patch to try to toggle
> > the DMA on and off?
>
> Oh. I pushed my dirty tree to
> git://git.breakpoint.cc/bigeasy/linux.git uart_v8_wip
>
> The top most commit does not setup dma at all and adds commented out
> code how to enable DMA via SCR or FCR register. With this I hit
> core-off. Once _one_ of the modes are enabled, it doesn't work anymore.
>
> I will try to address review comments tomorrow and hopefully post a v8
> based on -rc2. The same goes for your patch (which I will try tomorrow).
OK thanks, I'm seeing the same issue as you. And the idlest registers
don't show any blockers. Looking at the errata docs, seems like
"Usage Note 2.7" in sprz318f.pdf says:
Details When configured for DMA operations using smartidle mode (SYSC[4:3].IDLEMODE =
0x2), the UART module will not acknowledge incoming idle requests. As a consequence,
it can prevent L4 from going to idle.
When there are additional expected transfers, the UART should be placed in force-idle
mode.
So I've added also Paul to Cc, he may have better suggestions for the
hwmod flags to use. The experimental patch below seems to allow idling
for me, care to give it a try?
Regards,
Tony
8< --------------------
From: Tony Lindgren <tony@xxxxxxxxxxx>
Date: Thu, 28 Aug 2014 15:41:21 -0700
Subject: [PATCH] ARM: OMAP3: Use force-idle for UARTs because of DMA errata
In sprz318f.pdf Usage Note 2.7 says that UARTs cannot acknowledge
idle requests in smartidle mode when configure for DMA operations.
This prevents L4 from going idle. Sol et's use force-idle mode
instead.
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.mpu_irqs = omap2_uart1_mpu_irqs,
.sdma_reqs = omap2_uart1_sdma_reqs,
.main_clk = "uart1_fck",
- .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_TI81XXUART1_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
@@ -509,7 +511,9 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
.mpu_irqs = omap2_uart2_mpu_irqs,
.sdma_reqs = omap2_uart2_sdma_reqs,
.main_clk = "uart2_fck",
- .flags = DEBUG_TI81XXUART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_TI81XXUART2_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
@@ -529,7 +533,8 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
.sdma_reqs = omap2_uart3_sdma_reqs,
.main_clk = "uart3_fck",
.flags = DEBUG_OMAP3UART3_FLAGS | DEBUG_TI81XXUART3_FLAGS |
- HWMOD_SWSUP_SIDLE_ACT,
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = OMAP3430_PER_MOD,
@@ -559,7 +564,9 @@ static struct omap_hwmod omap36xx_uart4_hwmod = {
.mpu_irqs = uart4_mpu_irqs,
.sdma_reqs = uart4_sdma_reqs,
.main_clk = "uart4_fck",
- .flags = DEBUG_OMAP3UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_OMAP3UART4_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = OMAP3430_PER_MOD,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
