From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94D77C433E0 for ; Fri, 10 Jul 2020 03:29:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 628C42065C for ; Fri, 10 Jul 2020 03:29:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fUlGl4wf"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="f4ITW2HJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 628C42065C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Iph0GQAHVjk18OF37MxDNNm2XeGetKvHekoZAcuy+80=; b=fUlGl4wf/0ICTOmyrgNOBuA2U 0k9KUxJy1EFO3FN6KKWctYOEBi8uCiArbb0CZUo9pvVrxoWbsjkO6WSzbmJQKiMVFgwqPlNRR6ARG b4kr2aLrA+GyWrbc0x/BIgUYDRoPCB52D/Sjnuc+OkjDNuY9L/zY/JJH8UsXKtbl+7AXd5jErLjk8 YhTRWYwyOFpRYUFwVNk0ZBAdNcsoyEQS81DkTR1Q4GTOCitnv846DOQe3pdB7aCaxu51pEOT38uxj y8a8X995t4ueaOCCt/f0Ay82RrVWeFnABuyzqKTeyR7nqqQszqIRSiL6f+7dcU08SeoWxqioXvdx/ ZzPFAi/zg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtjhz-0001Rb-TX; Fri, 10 Jul 2020 03:28:19 +0000 Received: from mail-pj1-x1043.google.com ([2607:f8b0:4864:20::1043]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtjhx-0001R3-AR for linux-arm-kernel@lists.infradead.org; Fri, 10 Jul 2020 03:28:18 +0000 Received: by mail-pj1-x1043.google.com with SMTP id o22so2005523pjw.2 for ; Thu, 09 Jul 2020 20:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZxvdxfBILaYnXJQNJZ+x2bh2Jwx9Lc0OH867FBGnbFU=; b=f4ITW2HJaDpzmlUOq9gsCcnsNeXZ5kAxGhOJ1WsdU6gBY38JfAB7ZB1Gx59a4IBjah zA4j4PHyy+SO/ZuI+Nel6mFtFa33tswvI6qeX9gTLKSF1tDJx6lWL8IaQ1ybtqVB4vP3 FUgbKXueG7i4hIHeoJnHrFbdDWr9b/AA24yBVyFCU0AqFufs0S130Vik8qr14gB6xOeQ LjiLF+PpGsr+x6GRaIC6KqD5KYa+gIri9QIk9/gRFK7Z2/xLLTFiIIuvtW9Fdxr+Wh1C /P1PVyt9zt2czjYTNr/6HJ6iLXe4UCCj39nJ/Lj8Euc5P7DX3DrQ9H6WECyHeJNOZi1o r7Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZxvdxfBILaYnXJQNJZ+x2bh2Jwx9Lc0OH867FBGnbFU=; b=hYdqGBq9XyguBDH6H0kavCgXcGUIbpYibDDb7DsLaN8QtKOilNswskwZ6JqPEGB4/t XUIY2fgIIjvWWRMliDuzmbnP0asHMqROk+YKgV+E5irz/c+iDREtmtJlYoF429e4aGYW nmNTtVmzMjHJIYB+VncLU8b0E7TKAxVOr3mk9W0072oZLjcgg9YISN8sf3J6xlmbNLh3 05bDOiqreKfLRPyIgIUXqzzI4J/klBkYxZTsDDvnWlzmHD0Pxo2vMS+xanj01wwHp5yL viedG2btuiPICatLo9lK2EZUCBGHcFgLU+OhqND8kZFRVPq4jmFUT6zCXqKSXVWLD9S5 toew== X-Gm-Message-State: AOAM532ifXO8fArO6LEWaNL1uG//r9rsX5WIfUgOH3qVi2lk6sdzWjTo WI84I/fzSt/s4Ydc+uFFNYFuKfJ0lM4= X-Google-Smtp-Source: ABdhPJwC9zCaMf7YyiHY62PJWxCjHJlpdSjtle2sA2rDlVKwWWZXjY3oGD4zZ5m1JyPbt/hCXLnJyw== X-Received: by 2002:a17:902:ee8b:: with SMTP id a11mr45310502pld.26.1594351695336; Thu, 09 Jul 2020 20:28:15 -0700 (PDT) Received: from localhost ([122.172.34.142]) by smtp.gmail.com with ESMTPSA id a9sm4313852pfr.103.2020.07.09.20.28.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 20:28:14 -0700 (PDT) Date: Fri, 10 Jul 2020 08:58:12 +0530 From: Viresh Kumar To: Ionela Voinescu Subject: Re: [PATCH] arm64: topology: Don't support AMU without cpufreq Message-ID: <20200710032812.s7te6irtjiftljdb@vireshk-i7> References: <20200709101734.GB5623@arm.com> <20200709104048.emwuquj2qkyascb3@vireshk-i7> <20200709124630.GB15342@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200709124630.GB15342@arm.com> User-Agent: NeoMutt/20180716-391-311a52 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200709_232817_475434_D71502A1 X-CRM114-Status: GOOD ( 26.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Vincent Guittot Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 09-07-20, 13:46, Ionela Voinescu wrote: > I saw this case during FVP testing, although I acknowledge the 'virtual' > part of that platform [1]. But allowing this does enable AMU testing on > an AEM FVP. In kernel, we only support things that are in mainline, else we don't care about them. That's the general rule. And yeah I understand that this is early support for a new hardware, and so it is better to add code for things we are sure about. > While I completely understand the reasoning behind avoiding to introduce > large changes for small corner-case gains, I think even that is fine, if there is a problem to be solved it needs to be solved, big or small doesn't really matter. Just that it needs to be there in mainline. > the arguments for this > support was: > - (1) AMUs are a new feature and it will take some time until we see the > real usecases. That's always the case with early support for a > feature - we want to add it early to enable its use and testing, but > it will take some time to establish the true usecases. Exactly, and so people normally prefer to keep things simple until the time the needs arises for the same. A patch can be added later, its no big deal. But it should be added when we need it. > - (2) It literally needed 2 lines of code + the weak cpufreq function > to support this. Yeah, small or big doesn't really matter. > Given that I can't guarantee what hardware will or won't do, and given > that AMUs are an optional feature, I controlled the only thing I could: > the software :). By not making assumptions about the hardware, I ensured > that the code does not break the interaction between cpufreq use or AMU > use for frequency invariance. > > This will be nicer in the new code as the control will be at CPU level, > rather than policy level. I won't try to force you to remove this piece and will leave it for you to decide. But, I don't see a future system in mainline which uses AMU but doesn't have cpufreq for all its CPUs. And so I won't have kept code for that, even if it is just 2 lines. We can always add it back when required. Thanks for the review again Ionela. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel