RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

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

 



> From: Lucas Stach [mailto:l.stach@xxxxxxxxxxxxxx]
> Sent: Tuesday, October 13, 2015 5:01 AM

> So please help me to get this straight:
> 
> Errata I688 only affects OMAP4 which is consequently the only user of
> omap_interconnect_sync() in it's WFI enter sequence, which in turn is
> the only user of the SRAM scratch area to work around the erratum.
> 
> The OMAP specific barrier implementation which should be used also on
> other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
> the strongly ordered access.
> 
> So it is safe to say that we only ever need to run the initcall
> allocating the SRAM scratch area on OMAP4.

There are 2 separate things here.  One is the bus sync function and the other is the errata which requires a bus sync near WFI to avoid an errata.

The rational for the bus sync is similar to why there is a writel() and a writel_releaxed().  The bus sync has been used for a long time to ensure writes have landed and are not stuck in some posting buffer on path.   

A lot of historical drivers use a writel() where perhaps they could choose a more granular construct.  If drivers were audited maybe the bus sync could be minimized on writel() path.  Some writel's could be converted to use something like an mmiowb () or some appropriate option.  There is a lot of good information in the http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt document.  It seems every time I scan it some new aspect comes out.   

For many product launches I was part of in mobile >24 hour robustness was not achievable in non-trivial use cases without the serializing bus sync.  For CortexA9 ARM pushed in pl310sync and we added a bit to flush the interconnect posting buffer.   For a time in the mainline tree the bus sync's fell out as it seemed to complicate single kernel booting.   This has the effect of opening up folks to sparse hang issues like found in i688.  Re-closing this issue is the point of this mail series.

Regards,
Richard W.

��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f




[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