[PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.

Shilimkar, Santosh santosh.shilimkar at ti.com
Thu Sep 15 14:22:21 EDT 2011

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


More information about the linux-arm-kernel mailing list