Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3025988imu; Fri, 18 Jan 2019 03:34:15 -0800 (PST) X-Google-Smtp-Source: ALg8bN7tI5GR6EkicHU4mqJNcf8IPCxBtmFKlut9t7d2YOsNiZB/VVi8RGI/wFuyWxiXrpSUBJv3 X-Received: by 2002:a63:82c6:: with SMTP id w189mr17448107pgd.344.1547811255774; Fri, 18 Jan 2019 03:34:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547811255; cv=none; d=google.com; s=arc-20160816; b=qZbrV1kkNEalzJBNC+EhPQ+6uG9h0z+sWGJm3ByqD3Ei3bl3TT+tME+tl8QTCFJSoU tMOFSg+pPQp5GwJr5fSMhRK+sjNJkyM0xGuKtReKsHSFqSTXQL1rMES/SBZumBEPyYW2 g1TGzudoelUdcV+cQcXeOCA/iIfrts5p+0YClSOZfRC5Bt9pRB1PxK3WB7JOMftzYket j/in2aDJiQvGX3F4kOhlUC0YQNZWnr6DIKdOyzEr0CUUn0RH/GjK4T6CqfrY59nwQNt8 RLeIGigPR/nsO8FP6VtC+sJQWDfGbSTFwvV3kWqcPLrGcjPXtZBusns0ahgF+Y/cCcPE KGaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=TIObbq3gW9/yxz6x6djd5Ig4DH4lecwPDqbtDyTsHxE=; b=SOaTuSWIMvTlc9U/1kF6xWUNH0ffB1DHJ3VPp8jkcTLFcLObqWKyWV1pgQaSMSf8zc 2NoHqqbZoUmQuJzoWUE1Rhipd5g4GrsxdtJBHlc7s07xhoVLlaBmrHU7Fcdrshc2okKG 1+wh7aGzTYdnCPjm957QIj3t9LrY+SUwj+yRzjErr6OLejVQ9VF0POt/a3Gz/rR6L/6X c4OvtQ5iUB7rjfrCB7HHhPHxjm+Qf9iYsP8G6FNUxFVDaTZfc3FNOWu4QcyWyOzQ81X3 3ZhhZBX/j1fFqXI6jdlfZSg+VFyUTDywL0On1KCsBorqtFXAVMhla1IHJGOuG0AVc/sl TjvQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a28si4358102pgl.530.2019.01.18.03.33.59; Fri, 18 Jan 2019 03:34:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727212AbfARLcx (ORCPT + 99 others); Fri, 18 Jan 2019 06:32:53 -0500 Received: from foss.arm.com ([217.140.101.70]:55218 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727084AbfARLcx (ORCPT ); Fri, 18 Jan 2019 06:32:53 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 370D380D; Fri, 18 Jan 2019 03:32:53 -0800 (PST) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F3AFE3F557; Fri, 18 Jan 2019 03:32:50 -0800 (PST) Date: Fri, 18 Jan 2019 11:32:42 +0000 From: Sudeep Holla To: Pramod Kumar Cc: Catalin Marinas , Will Deacon , Suzuki K Poulose , Dave Martin , Mark Rutland , Rob Herring , Lorenzo Pieralisi , Steve Capper , Sudeep Holla , BCM Kernel Feedback , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug is supported Message-ID: <20190118113242.GA8928@e107155-lin> References: <1547790380-6276-1-git-send-email-pramod.kumar@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1547790380-6276-1-git-send-email-pramod.kumar@broadcom.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 18, 2019 at 11:16:20AM +0530, Pramod Kumar wrote: > If CPU hotplug is supported, ipi_cpu_stop should use PSCI cpudie > call to stop the CPU. This call ensures L1/L2 cache flush, > CPUs cache-cohenrecy setting w.r.to interconnect. > Firstly, this is not specific to PSCI and I don't see any PSCI calls as $subject claims. Next, you fail to explain why do you have to ensure caches are cleaned and why do you need that in ipi_cpu_stop ? What's the use case ? > Apart from this, this gives control to f/w to reduce power consumption > by take appropriate decesion on power rails for plugging-out core. > May be, but ipi_cpu_stop is used is machine reboot/poweroff/halt which may restart or poweroff the system, powering down individual CPUs is not necessary and may consume lot of time in systems with large number of CPUs. It would be good to know the use-case in case I am missing to consider that. -- Regards, Sudeep