From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Shilimkar, Santosh" Subject: Re: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers. Date: Fri, 16 Sep 2011 17:31:53 +0530 Message-ID: References: <1315144466-9395-1-git-send-email-santosh.shilimkar@ti.com> <1315144466-9395-3-git-send-email-santosh.shilimkar@ti.com> <20110913202701.GF24252@atomide.com> <4E7080F8.9020302@ti.com> <87obyl7mj8.fsf@ti.com> <20110915175354.GW24252@atomide.com> <20110915194330.GC2284@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from na3sys009aog117.obsmtp.com ([74.125.149.242]:56932 "EHLO na3sys009aog117.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751968Ab1IPMCO convert rfc822-to-8bit (ORCPT ); Fri, 16 Sep 2011 08:02:14 -0400 Received: by gwb15 with SMTP id 15so3967674gwb.5 for ; Fri, 16 Sep 2011 05:02:13 -0700 (PDT) In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: Kevin Hilman , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk, rnayak@ti.com, Richard Woodruff On Fri, Sep 16, 2011 at 1:30 AM, Shilimkar, Santosh wrote: > On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren wro= te: >> * Shilimkar, Santosh [110915 10:49]: >>> On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren = wrote: >>> > >>> > Please also include the errata in the description and set it up w= ith >>> > a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRAT= A_XXXXXX. >>> > >>> Sure. >>> It's a =A0TI ERRATA. >> >> OK >> >>> > Also it would be best to apply this fix at the end of the PM seri= es so >>> > it is easier to verify the bug and potentially remove the hack if >>> > a better fix is ever available. >>> > >>> As such order doesn't matter much because it can be removed either = way >>> even if it is in the beginning of the series with KCONFIG entry. >>> >>> But I can change the order if you prefer that way. >> >> Well it seems that it's the omap4_finish_suspend in this series that >> can be used to trigger the bug, although the bug has been around for >> few years. So then instead of mentioning random hangups you can have >> a better description with something like "Patch xyz added PM idle >> support for omap4, however bug 123 causes so and so. Fix the issue >> with blah blah". >> > Sounds good . > >> Also, if you have some easy way to reproduce the bug maybe mention >> that too? That would make it easy to verify if issue has been fixed. >> Just for record, Below are the errata details. ERRATA: i688: Async Bridge Corruption If a data is stalled inside asynchronous bridge because of backpressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until n= ext reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path be= tween MPU to EMIF, MPU to L3 interconnect and Cortex M3 to Emif . This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software whenexecuting WFI) WORKAROUND All the initiators connected through Async Bridge must ensure that data path is properly drained before issuing WFI. This condition will b= e met if one Strongly ordered access is performed to the target right before executing the WFI. > There are some multimedia usecases where the bug was discovered > but on mainline obviously we don't have that support. > > I will check with IP folks if any other simple test-case is possible > to reproduce the issue and If I find one, will mention that. > We have a GFX usecase which demonstrate this issue but can't be tested on mainline sicne no GFX support. But the same patch is already in the product line which has fixed the GFX usecase issue. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Shilimkar, Santosh) Date: Fri, 16 Sep 2011 17:31:53 +0530 Subject: [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers. In-Reply-To: References: <1315144466-9395-1-git-send-email-santosh.shilimkar@ti.com> <1315144466-9395-3-git-send-email-santosh.shilimkar@ti.com> <20110913202701.GF24252@atomide.com> <4E7080F8.9020302@ti.com> <87obyl7mj8.fsf@ti.com> <20110915175354.GW24252@atomide.com> <20110915194330.GC2284@atomide.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Sep 16, 2011 at 1:30 AM, Shilimkar, Santosh wrote: > On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren wrote: >> * Shilimkar, Santosh [110915 10:49]: >>> On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren wrote: >>> > >>> > Please also include the errata in the description and set it up with >>> > a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX. >>> > >>> Sure. >>> It's a ?TI ERRATA. >> >> OK >> >>> > Also it would be best to apply this fix at the end of the PM series so >>> > it is easier to verify the bug and potentially remove the hack if >>> > a better fix is ever available. >>> > >>> As such order doesn't matter much because it can be removed either way >>> even if it is in the beginning of the series with KCONFIG entry. >>> >>> But I can change the order if you prefer that way. >> >> Well it seems that it's the omap4_finish_suspend in this series that >> can be used to trigger the bug, although the bug has been around for >> few years. So then instead of mentioning random hangups you can have >> a better description with something like "Patch xyz added PM idle >> support for omap4, however bug 123 causes so and so. Fix the issue >> with blah blah". >> > Sounds good . > >> Also, if you have some easy way to reproduce the bug maybe mention >> that too? That would make it easy to verify if issue has been fixed. >> Just for record, Below are the errata details. ERRATA: i688: Async Bridge Corruption If a data is stalled inside asynchronous bridge because of backpressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until next reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path between MPU to EMIF, MPU to L3 interconnect and Cortex M3 to Emif . This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software whenexecuting WFI) WORKAROUND All the initiators connected through Async Bridge must ensure that data path is properly drained before issuing WFI. This condition will be met if one Strongly ordered access is performed to the target right before executing the WFI. > There are some multimedia usecases where the bug was discovered > but on mainline obviously we don't have that support. > > I will check with IP folks if any other simple test-case is possible > to reproduce the issue and If I find one, will mention that. > We have a GFX usecase which demonstrate this issue but can't be tested on mainline sicne no GFX support. But the same patch is already in the product line which has fixed the GFX usecase issue. Regards Santosh