[PATCH] arm: Add Arm Erratum 773769 for Large data RAM latency.

[Doug Anderson]

Hi,

On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Jan 08, 2014 at 08:21:21AM -0800, Doug Anderson wrote:
>> WIll,
>>
>> Thanks for your comments!
>>
>> On Wed, Jan 8, 2014 at 6:35 AM, Will Deacon <will.deacon at arm.com> wrote:
>> > NAK. Whilst I appreciate that you may not be able to fix your bootloader,
>> > this isn't the right change to make in the kernel. Blindly changing memory
>> > latencies is likely to do more harm than good for a multi-platform kernel,
>> > even if it works for exynos 5250. The only alternative I can think of (if you
>> > have to make a mainline kernel change) is to restrict the clock frequencies at
>> > which the CPU is allowed to run, although that obviously requires some
>> > investigation in order to determine how viable it is for your SoC.
>
> +1
>
>> I'll start off by saying that I'm totally OK if mainline doesn't want
>> this fixed.  If mainline is not interested in running reliably on
>> exynos5250-based products then there's nothing I can do about it.  It
>> seems unfortunate, but I'm not going to get into a shouting match
>> about it.
>
> No, we're saying to put the work-around in the boot loader, not the kernel.

Unfortunately the resume path of the firmware runs from Read Only
firmware code (yes, it sucks), so it's not totally trivial to fix.  It
would be possible for someone to unscrew their write protect switch
and update their RO firmware, but that doesn't help the average user.

Olof came up with the idea that you could update the RW firmware
(affects initial boot) and then cache away the value and restore it in
the kernel after resume.  That would still require a kernel patch but
perhaps a less objectionable one.  ...of course if writing this
register is a problem in secure mode then maybe that patch would be
NAKed anyway.


>> * Is guarded by a runtime check of the revision number so that it
>> doesn't run on unaffected A15 revisions.
>
> So what if the A15 reports an affected revision, but the SoC integrator
> has fixed the problem - why should they have to put up with the work-
> around being applied on their silicon?

That's one I didn't think about, you're right.  ...but we're really
getting into hypothetical situations here.  Are there any r2p0
products that have such a fix (and thus require a latency of >= 4)?


> We've been through these arguments many times, you're not the first to
> raise it, and we've decided upon the policy.  We want as _few_ work-
> arounds in the kernel as possible, because applying the work-arounds
> is very problematical with the mixture of secure and non-secure booting.

OK, fair enough.  If we want no workaround here then we can drop this patch.


I'd guess that the way forward is:

* Land kernel workaround locally in Chromium tree

* I'll try to land FW change locally in at least one Chromium branch.
If we were to get a new RO build ever (seems unlikely at this point)
it would be fixed for upstream kernels.  If we were to get a new RW
build (seems unlikely, but at least less unlikely) it would be fixed
if someone landed a kernel patch to save/restore this register across
suspend/resume.

* If Joe Upstream wants to run an upstream kernel on some type of
exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10
are the ones I know of) then he will deal with the small number of
crashes or figure out a solution.


-Doug