On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * 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. > Sure. It's a TI ERRATA. > 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. Regards Santosh -- 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
