From: Paul Burton <paul.burton@imgtec.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>,
"Steven J. Hill" <Steven.Hill@imgtec.com>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
"ralf@linux-mips.org" <ralf@linux-mips.org>
Subject: Re: [PATCH] MIPS: Fix errata for some 1074K cores.
Date: Thu, 12 Sep 2013 16:12:37 +0100 [thread overview]
Message-ID: <5231D9E5.2080002@imgtec.com> (raw)
In-Reply-To: <CAGVrzcY_OWUSK4dfZ8fnV49ELSYE6exSYQi5AwxuGoKnvx5Rtg@mail.gmail.com>
Agreed, my point is not about your code but your commit message. If I'm
reading a commit which works around CPU errata I should not have to go
and ask the hardware engineers or even read an errata document in order
to know what you're doing. Your commit message should explain the
errata, its effects and how your patch works around the problem.
Paul
On 12/09/13 16:05, Florian Fainelli wrote:
> 2013/9/12 Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>:
>> Treat it as is.
>>
>> It is a dirty laundry of HW engineers and you may need to communicate with them or read Errata docs on CPU.
>>
>> If it is about a way how it is written - ask Steven, initially it was in mainland probe code but he think it should be a separate function. I just corrected him, pointing that erratas on 74K and 1074K are different. But because he insist on having the same CPU_74K for both, so...
> If you take a look at another CPU company such as ARM, they provide
> lengthy explanations for their various Erratas:
>
> config PJ4B_ERRATA_4742
> bool "PJ4B Errata 4742: IDLE Wake Up Commands can Cause the
> CPU Core to Cease Operation"
> depends on CPU_PJ4B && MACH_ARMADA_370
> default y
> help
> When coming out of either a Wait for Interrupt (WFI) or a Wait for
> Event (WFE) IDLE states, a specific timing sensitivity exists between
> the retiring WFI/WFE instructions and the newly issued subsequent
> instructions. This sensitivity can result in a CPU hang scenario.
> Workaround:
> The software must insert either a Data Synchronization Barrier (DSB)
> or Data Memory Barrier (DMB) command immediately after the WFI/WFE
> instruction
>
> I really think that you should aim for the same level of information
> so that people know whether this is relevant for their platform,
> whether they have the ECO applied etc...
next prev parent reply other threads:[~2013-09-12 15:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 20:01 [PATCH] MIPS: Fix errata for some 1074K cores Steven J. Hill
2013-09-12 9:39 ` Paul Burton
2013-09-12 9:39 ` Paul Burton
2013-09-12 14:57 ` Leonid Yegoshin
2013-09-12 15:05 ` Florian Fainelli
2013-09-12 15:12 ` Leonid Yegoshin
2013-09-12 15:12 ` Paul Burton [this message]
2013-09-12 15:30 ` Leonid Yegoshin
2013-09-12 15:50 ` Florian Fainelli
2013-09-12 16:02 ` Steven J. Hill
2013-09-12 16:02 ` Steven J. Hill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5231D9E5.2080002@imgtec.com \
--to=paul.burton@imgtec.com \
--cc=Leonid.Yegoshin@imgtec.com \
--cc=Steven.Hill@imgtec.com \
--cc=f.fainelli@gmail.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.