* Shilimkar, Santosh <santosh.shilimkar@xxxxxx> [110915 09:51]: > On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman <khilman@xxxxxx> wrote: > > Santosh <santosh.shilimkar@xxxxxx> writes: > > > >> On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote: > >>> * Santosh Shilimkar<santosh.shilimkar@xxxxxx> [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 -- 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
