From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Thu, 15 Sep 2011 10:53:54 -0700 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> Message-ID: <20110915175354.GW24252@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Shilimkar, Santosh [110915 09:51]: > On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman wrote: > > Santosh writes: > > > >> On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote: > >>> * Santosh Shilimkar ?[110904 06:22]: > >>>> On OMAP4 SOC intecronnects has many write buffers in the async bridges > >>>> and they can be drained only with stongly ordered accesses. > >>> > >>> This is not correct, strongly ordered access does not guarantee > >>> anything here. If it fixes issues, it's because it makes the writes > >>> to reach the device faster. Strongly ordered does not affect anything > >>> outside ARM, so the bus access won't change. > >>> > >> What I said is the aync bridges WB and what is said is correct > >> from MPU accesses point of view. > >> > >> It's not about faster or slower. With device memory the, writes > >> can get stuck into write buffers where as with SO, the write buffers > >> will be bypassed. > >> > >> The behaviours is limited to the MPU side async bridge boundary which > >> is the problem. The statement is not for l3 and l4 interconnect which > >> probably you mean. > >> > >> There is always a hardware signal to communicate CPU at async bridges > >> to ensure that data is not stuck in these bridges before CPU > >> clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices > >> and the dual channel makes it even worst since both pipes have the > >> same BUG. So what we are doing is issuing SO write/read accesses > >> on these pipes so that there is nothing stuck there before MPU > >> hits low power states and also avoids any race conditions when > >> both channels are used together by some initiators. The behaviour > >> is validated at RTL level and there is no ambiguity about it. > >> > >> May be you have mistaken the L3 and L4 as the interconnect levels > >> in this case. > > > > Sounds to me like the changelog needs to be a bit more verbose. > > > > Remember, we're all probably going to forget the gory details of this in > > a few months and want to be able to go back to the code w/changelog to > > refresh our memories. > > > Change log was accurate but I agree it needs more description to make it > clear. I plan to update it. 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. 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. Regards, Tony