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

[Shilimkar, Santosh]

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.
>
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