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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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 77DBCC468D8 for ; Mon, 10 Jun 2019 15:55:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5004F2089E for ; Mon, 10 Jun 2019 15:55:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="vCBfA3Km" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403984AbfFJPzQ (ORCPT ); Mon, 10 Jun 2019 11:55:16 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:34417 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391358AbfFJPzQ (ORCPT ); Mon, 10 Jun 2019 11:55:16 -0400 Received: by mail-vs1-f65.google.com with SMTP id q64so5691643vsd.1 for ; Mon, 10 Jun 2019 08:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eJ960EUK4M88NTDJHb1rKy4PnhRaQvW8Nj+C4ov1eV0=; b=vCBfA3KmfrlpdkfwvUkrPRXgpjj0KDLsG7IqaJiYABwd5Pcyt+37mq5KWs4wPSGqMb 8ZgO+v9HFp5+yUBCsWM3EzZH87jxKU3TpzYbeFbOOK7m8bhdQ1VpJzZg2LQ3MfAea/mO eIND2griYlCH1pm58X4Ot68AJrGmrqHsHx/39nYjlnDkDZjrdt6+jVL/CSvvh9a4M0lm RTE6Tl9praUVHc0Tmaeiz3dcU4blbB0iDAGmXz+xY0nJeRKi3vN6nhssHg1abNM+4se2 nc4Ba32motZk89uankg8NcXb2RU99K3kViAN47xvTlR682A9KwMEfT3SmCv+tcveqfdQ +O7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eJ960EUK4M88NTDJHb1rKy4PnhRaQvW8Nj+C4ov1eV0=; b=pq1JHxd6+Zqh6JgQw/NMa8/P+1gPTaKNlpdAxZ1mOsYyAOcgZphGk99wVLJrf4DZHb UVGxIiDrgOCiEMS6jg7zp0o+daItYUngBrlmpv7pvcyiDMezeelLBW2FCb9RqLc110CE 2uwi1PAdsy9pQEdD83c9bEmk9IvYmegZd+4PttKNovs5gLEJyi7yA6Q7gJCY69xSKZ7w m4S6hr6avttU1Ui4u6wmQHJ4HGBHybaP9KRMWHbIGrtc4noTIFMJSbV4N/23Cq1h/36Y oa3cLZoKD5HeUyxC/LAFBCsyz+Sgbmi5gq79wxuroID1jGrebDVOCSXp8x946ki8K6Je mTQA== X-Gm-Message-State: APjAAAXzodnJQWGRL5NZi77MYEnhmBsl2DZmFVqkOQvmOxWSFXCNZWUG zIBf0UUOZzrt0p+Lc7Gb6sUIauOiiWLN5kxF+GfNRA== X-Google-Smtp-Source: APXvYqyKa1UWfLl1PSfzv6wP9x21u1pRGC0+qtdGCuyShRG80yR2Bgm8tFZ6P+m7SezHV6nB/wuI1N1s+r9iik+R06c= X-Received: by 2002:a67:706:: with SMTP id 6mr20519578vsh.200.1560182115587; Mon, 10 Jun 2019 08:55:15 -0700 (PDT) MIME-Version: 1.0 References: <20190513192300.653-1-ulf.hansson@linaro.org> <20190607154210.GJ15577@e107155-lin> <20190607193407.GB24059@builder> <20190610103225.GA26602@e107155-lin> In-Reply-To: <20190610103225.GA26602@e107155-lin> From: Ulf Hansson Date: Mon, 10 Jun 2019 17:54:39 +0200 Message-ID: Subject: Re: [PATCH 00/18] ARM/ARM64: Support hierarchical CPU arrangement for PSCI To: Sudeep Holla , Lorenzo Pieralisi Cc: Bjorn Andersson , "Rafael J. Wysocki" , Mark Rutland , Linux ARM , "Rafael J . Wysocki" , Daniel Lezcano , "Raju P . L . S . S . S . N" , Amit Kucheria , Stephen Boyd , Niklas Cassel , Tony Lindgren , Kevin Hilman , Lina Iyer , Viresh Kumar , Vincent Guittot , Geert Uytterhoeven , Souvik Chakravarty , Linux PM , linux-arm-msm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Mon, 10 Jun 2019 at 12:32, Sudeep Holla wrote: > > On Fri, Jun 07, 2019 at 12:34:07PM -0700, Bjorn Andersson wrote: > > On Fri 07 Jun 08:42 PDT 2019, Sudeep Holla wrote: > > > > > On Tue, May 14, 2019 at 10:58:04AM +0200, Ulf Hansson wrote: > > > > On Tue, 14 May 2019 at 10:08, Rafael J. Wysocki wrote: > > > > > > > > > > On Mon, May 13, 2019 at 9:23 PM Ulf Hansson wrote: > > > > > > > > > > > > This series enables support for hierarchical CPU arrangement, managed by PSCI > > > > > > for ARM/ARM64. It's based on using the generic PM domain (genpd), which > > > > > > recently was extended to manage devices belonging to CPUs. > > > > > > > > > > ACK for the patches touching cpuidle in this series (from the > > > > > framework perspective), but I'm assuming it to be taken care of by > > > > > ARM/ARM64 maintainers. > > > > > > > > Thanks for the ack! Yes, this is for PSCI/ARM maintainers. > > > > > > > > BTW, apologize for sending this in the merge window, but wanted to > > > > take the opportunity for people to have a look before OSPM Pisa next > > > > week. > > > > > > > > > > I will start looking at this series. But I would request PSCI/other > > > maintainers to wait until we see some comparison data before we merge. > > > > What comparison are you asking for here? Do you want to see the > > improvement this series gives or are you hoping to compare it with some > > other mechanism? > > > > OK, I have mentioned this many times already, let me repeat it again. > This series adds an alternative to the existing PC mode of CPU idle > management. And it's clear that the main reason for the same is the > improvement OSI mode offers vs the PC mode. I am asking the comparison > for the same. And yes we need to compare apples with apples and not > oranges here. In the cover letter you see the two main reasons behind this series. Yeah, OSI support is a part of the series, but OSI or PC mode is orthogonal to the overall changes this series implements. When it comes to comparing OSI mode vs PC mode, let's try to avoid that tiring discussion again, please. :-) My summary from the earlier ones, is that because the PSCI spec includes support for OSI, we should also support it in the kernel (and ATF). In a discussion offlist, Lorenzo agreed that it's okay to add, without an apple to apple comparison. Maybe Lorenzo can fill in and state this publicly, to save us all some time? My final point in regards to the OSI mode support, it's a minor part of the series. I don't see how that should hurt from a maintenance point of view, or perhaps I am wrong? In any case, I offer my help with review/maintenance in any form as you may see need/fit. [...] Kind regards Uffe