From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Sep 2013 17:30:34 +0200 (CEST) Received: from multi.imgtec.com ([194.200.65.239]:61500 "EHLO multi.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S6823119Ab3ILPacMSsmQ (ORCPT ); Thu, 12 Sep 2013 17:30:32 +0200 Message-ID: <5231DE0F.8080302@imgtec.com> Date: Thu, 12 Sep 2013 08:30:23 -0700 From: Leonid Yegoshin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Burton CC: Florian Fainelli , "Steven J. Hill" , "linux-mips@linux-mips.org" , "ralf@linux-mips.org" Subject: Re: [PATCH] MIPS: Fix errata for some 1074K cores. References: <1378929708-7253-1-git-send-email-Steven.Hill@imgtec.com> <52318BC6.7030903@imgtec.com> <5231D9E5.2080002@imgtec.com> In-Reply-To: <5231D9E5.2080002@imgtec.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.65.146] X-SEF-Processed: 7_3_0_01192__2013_09_12_16_30_26 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 37808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Leonid.Yegoshin@imgtec.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips It is not mine, I just fixed an existent code which applies a wrong errata to 1074K. Errata fix did exist before me. - Leonid. On 09/12/2013 08:12 AM, Paul Burton wrote: > 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 : >>> 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... >