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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux