From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753663AbbDMMGo (ORCPT ); Mon, 13 Apr 2015 08:06:44 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:16452 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751956AbbDMMGh (ORCPT ); Mon, 13 Apr 2015 08:06:37 -0400 X-AuditID: cbfee68f-f793b6d000005f66-73-552bb14abf51 Message-id: <552BB14A.6010205@samsung.com> Date: Mon, 13 Apr 2015 21:06:34 +0900 From: Chanwoo Choi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-version: 1.0 To: Mark Rutland Cc: "kgene@kernel.org" , "arnd@arndb.de" , "olof@lixom.net" , Marc Zyngier , Catalin Marinas , Will Deacon , "inki.dae@samsung.com" , "chanho61.park@samsung.com" , "sw0312.kim@samsung.com" , "jh80.chung@samsung.com" , "ideal.song@samsung.com" , "a.kesavan@samsung.com" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-samsung-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC References: <1426637856-3730-1-git-send-email-cw00.choi@samsung.com> <1426637856-3730-2-git-send-email-cw00.choi@samsung.com> <20150330160940.GA13731@leverpostej> <5519E2B6.2030905@samsung.com> <20150402173558.GB30669@leverpostej> <551DD321.6030707@samsung.com> <20150407102523.GA23190@leverpostej> <20150413105618.GD4076@leverpostej> In-reply-to: <20150413105618.GD4076@leverpostej> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsWyRsSkQNdro3aowdnHVhaP1yxmsvg76Ri7 xftlPYwWl/drW8w/co7VYtff+4wWk+5PYLG48auN1aL/8Wtmi02Pr7FaXN41h81ixvl9QF13 /rFZLL1+kcni1PXPQLHJL9ksXn48weIg6LFm3hpGj9+/JjF6bFrVyeaxeUm9x5UTTawefVtW MXp83iQXwB7FZZOSmpNZllqkb5fAlbG+06RgrkTF/qOHGBsYG4S7GDk5JARMJD7PnsAOYYtJ XLi3nq2LkYtDSGApo8TarqVMMEXzbs5ghEhMZ5RY/7mZFcJ5wCjxpeM7WBWvgJbEr68XWUBs FgFVidmHF7OC2GxA8f0vbrCB2KICYRIrp19hgagXlPgx+R6YLSKgLtGz6wsLyFBmgT1sEhP2 7WYGSQgLREq837+eBWLbNSaJoytmgh3LKWAgcfPIQrBuZgEdif2t09ggbHmJzWveMkPcvZRD 4uWUWIiLBCS+TT4EVM8BFJeV2HQAqkRS4uCKGywTGMVmIblpFpKps5BMXcDIvIpRNLUguaA4 Kb3IWK84Mbe4NC9dLzk/dxMjMNpP/3vWv4Px7gHrQ4wCHIxKPLwX7miFCrEmlhVX5h5iNAW6 YiKzlGhyPjCl5JXEGxqbGVmYmpgaG5lbmimJ8y6U+hksJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgbHZvHOSs+6HvEs7/oirJNezFPLuTH94wjryZEj9pt9bDaIZ1dQbUhVTLuQtl2u4oK4s +Fdz3/KU5J8foo+p9nAunFgQcebtvXC1p5oRJ0ocN3IlxH1LiQxMLvA/0SXNf+rG+y+LTp1p efJb7NAZkV2p116fVnnbUShZd9By+QLRLz+vJoekz1FiKc5INNRiLipOBAD2D9ZH8QIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsVy+t9jQV2vjdqhBvv2G1g8XrOYyeLvpGPs Fu+X9TBaXN6vbTH/yDlWi11/7zNaTLo/gcXixq82Vov+x6+ZLTY9vsZqcXnXHDaLGef3AXXd +cdmsfT6RSaLU9c/A8Umv2SzePnxBIuDoMeaeWsYPX7/msTosWlVJ5vH5iX1HldONLF69G1Z xejxeZNcAHtUA6NNRmpiSmqRQmpecn5KZl66rZJ3cLxzvKmZgaGuoaWFuZJCXmJuqq2Si0+A rltmDtAHSgpliTmlQKGAxOJiJX07TBNCQ9x0LWAaI3R9Q4LgeowM0EDCGsaM9Z0mBXMlKvYf PcTYwNgg3MXIySEhYCIx7+YMRghbTOLCvfVsXYxcHEIC0xkl1n9uZoVwHjBKfOn4zgRSxSug JfHr60UWEJtFQFVi9uHFrCA2G1B8/4sbbCC2qECYxMrpV1gg6gUlfky+B2aLCKhL9Oz6wgIy lFlgD5vEhH27mUESwgKREu/3r2eB2HaNSeLoipnsIAlOAQOJm0cWgnUzC+hI7G+dxgZhy0ts XvOWeQKjwCwkS2YhKZuFpGwBI/MqRtHUguSC4qT0XEO94sTc4tK8dL3k/NxNjOBk8kxqB+PK BotDjAIcjEo8vBfuaIUKsSaWFVfmHmKU4GBWEuH9vEA7VIg3JbGyKrUoP76oNCe1+BCjKTAM JjJLiSbnAxNdXkm8obGJmZGlkbmhhZGxuZI47xxduVAhgfTEktTs1NSC1CKYPiYOTqkGRseg T88Pznp+QafD31s4WuAo91SdaRreakUqmz6GndzwY5ZYY7rnkSciGy/NqAvXN/gS05QhYvPQ 1WHOAmbBcvPGqkkV/+wLlnpoXQ7cezpPSPFq0sWw/RdSpXQvbJv4Tz/i28pfn20F151PX/tu 0bWkyKmBr59yfTA0CN6xYeGlug0TmaQvxyixFGckGmoxFxUnAgD7PQ3uPAMAAA== DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On 04/13/2015 07:56 PM, Mark Rutland wrote: > Hi Chanwoo, > > Could you please reply to the below? > > Without an answer I'm going to have to ask for the patch to be unqueued > for the moment, and I'd prefer that we came to a solution instead. I'm sorry about late reply. > > Thanks, > Mark. > > On Tue, Apr 07, 2015 at 11:25:27AM +0100, Mark Rutland wrote: >>>>>> I'm very worried about adding a DT that's known broken, especially when >>>>>> we have no idea as to if/when the FW will be fixed judging from prior >>>>>> replies. >>>>> >>>>> As I replied, I can not fix the FW because I don't have any code of FW. >>>> >>>> Surely you are able to contact those who do? >>>> >>>>> I don't have any solution to fix it on Linux kernel level. >>>>> >>>>> So, If you agree, I can add the comment of CPU0 hotplug issue on DT file. >>>> >>>> I disagree. I do not want to add a DT that is known to be broken; >>>> especially when we have no idea how to fix it. It creates long-term >>>> maintenance pain for everyone, and marginal gain for few. A comment does >>>> nothing to aid the end-user. >>>> >>>> So NAK to the PSCI node and PSCI enable method in this dts until we >>>> either have a working firmware, or a reasonable mechanism to handle the >>>> deficiency. >>> >>> There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working. >> >> I understand that, but the issue with CPU0 is still a blocker from my >> PoV. >> >>> To fix this issue, we must need the help of firmware developer. >>> But, We never get the any help. >> >> Previously you said that you did not have access to the source code >> rather than not having help from the relevant firmware engineers. I take >> it you have informed them of the issue with CPU0? I didn't ask any help to firmware engineer because I didn't know who firmware engineer and also didn't access the source code. If I knew the engineer and can access them, I would have asked some help to them or inquired the reason about CPU0 not hotplugged. >> >>> Also, as I mentioned on previous mail, all Exynos SoCs can not turn >>> off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible. >> >> While that may be the case, PSCI is a more generic standard, and it is >> used on systems where CPU0 can be hot unplugged. So Exynos-specific >> details cannot dictate how the kernel PSCI driver should behave. >> >> Is there a particular reason that CPU0 cannot be hotplugged? Unfortunately, I don't know correctly why Exynos SoC cannot hotplug the CPU0. But, IMHO, SoC had to maintain at least online core for operation. Just Exynos SoC has remained the CPU0 as at least online core. >> >> In PSCI 0.2 and later it's possible to determine whether a trusted OS >> prohibits a core from being hotplugged, but this mechanism doesn't exist >> in earlier versions. I am not averse to adding a property to PSCI 0.1 >> to mark a CPU as not being hotpluggable if there is a fundamental reason >> (i.e. not simply a bug) for this being the case. Thanks, Chanwoo Choi