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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 CA32EC76188 for ; Tue, 16 Jul 2019 10:28:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A3BD720880 for ; Tue, 16 Jul 2019 10:28:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563272882; bh=InV49k/g4n8kkX89qOOPmJMNqj/Q2fuW/aBD6hhUrXA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=AyEZ8HCa76Thh7BdgsphnPnwDhNGfkPibThMLLdwsedvPi+TUam+uRSxGgD3T8POb WC92bEFF5DLEmQuVWrh3zJAGaAiJYH0jyGjaP/tWsQopHqPmRV0Ooyr0Qh0H2emYMS cNVhaqdRIGKiFqrlLA9KIc3dSdtPTMQ1JJ8n/cOI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733117AbfGPK17 (ORCPT ); Tue, 16 Jul 2019 06:27:59 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:33134 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732319AbfGPK17 (ORCPT ); Tue, 16 Jul 2019 06:27:59 -0400 Received: by mail-ot1-f68.google.com with SMTP id q20so20470120otl.0; Tue, 16 Jul 2019 03:27:58 -0700 (PDT) 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=InV49k/g4n8kkX89qOOPmJMNqj/Q2fuW/aBD6hhUrXA=; b=LP9UCFk/txz+8PX9fFtv/tFMlGmWO8p/SA855m/EOd/YAEFUGuqISAykuCTSFZjPWr eyb4/WBRLWZytdBG90l4K5smP29fTIINGjnQCE8qD9v8khA6CuYYnHyA8lYpRMwjYZOi L+lJzASL07W2Ko9IolEPteOZqGDXKrVhyBHxViB1aKO+lvViVtXKUEdsf313850UosI3 FvWzz79zOo06xaLvaUwqQ4t4HU9d2alXcgK11I/eWak+k/qWRLCwfwCUX+AI2XJVDpZ8 QQaLzvh7DPqpkJKskGCC2UbPYLxDsNSDckCmd5yWo58q7MK5TgXumw74lcSqmyNnH0wL 7Apg== X-Gm-Message-State: APjAAAVOs1jCA+1qM2yVYeNozrlAU4wThENjruPto7PDM9QAnPCuX3t7 An4o2h11KWH5DMji4D6pk9XQMf/V3L/yaXef1NY= X-Google-Smtp-Source: APXvYqwNxa4ESy69KwPnztnMj6Vvcz27ajFqshxcVQs8WVfJTe1ykblJ31kt949Zta05jFdEjaTLyPSqql/gvXR4C4Y= X-Received: by 2002:a05:6830:8a:: with SMTP id a10mr18446800oto.167.1563272877613; Tue, 16 Jul 2019 03:27:57 -0700 (PDT) MIME-Version: 1.0 References: <20190716101416.ntk353cfnrcykoek@vireshk-i7> In-Reply-To: <20190716101416.ntk353cfnrcykoek@vireshk-i7> From: "Rafael J. Wysocki" Date: Tue, 16 Jul 2019 12:27:46 +0200 Message-ID: Subject: Re: [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests To: Viresh Kumar Cc: "Rafael J. Wysocki" , Rafael Wysocki , Amit Daniel Kachhap , Benjamin Herrenschmidt , Daniel Lezcano , Eduardo Valentin , Erik Schmauss , Greg Kroah-Hartman , Javi Merino , Len Brown , Robert Moore , Zhang Rui , Linux PM , Vincent Guittot , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , dri-devel , ACPI Devel Maling List , "open list:DOCUMENTATION" , "open list:FRAMEBUFFER LAYER" , Linux Kernel Mailing List , linuxppc-dev 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 Tue, Jul 16, 2019 at 12:14 PM Viresh Kumar wrote: > > On 16-07-19, 12:06, Rafael J. Wysocki wrote: > > On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote: > > > > > > Hello, > > > > > > Now that cpufreq core supports taking QoS requests for min/max cpu > > > frequencies, lets migrate rest of the users to using them instead of the > > > policy notifiers. > > > > Technically, this still is linux-next only. :-) > > True :) > > > > The CPUFREQ_NOTIFY and CPUFREQ_ADJUST events of the policy notifiers are > > > removed as a result, but we have to add CPUFREQ_CREATE_POLICY and > > > CPUFREQ_REMOVE_POLICY events to it for the acpi stuff specifically. So > > > the policy notifiers aren't completely removed. > > > > That's not entirely accurate, because arch_topology is going to use > > CPUFREQ_CREATE_POLICY now too. > > Yeah, I thought about that while writing this patchset and > coverletter. But had it not been required for ACPI, I would have done > it differently for the arch-topology code. Maybe direct calling of > arch-topology routine from cpufreq core. I wanted to get rid of the > policy notifiers completely but I couldn't find a better way of doing > it for ACPI stuff. > > > > Boot tested on my x86 PC and ARM hikey board. Nothing looked broken :) > > > > > > This has already gone through build bot for a few days now. > > > > So I'd prefer patches [5-8] to go right after the first one and then > > do the cleanups on top of that, as somebody may want to backport the > > essential changes without the cleanups. > > In the exceptional case where nobody finds anything wrong with the > patches (highly unlikely), do you want me to resend with reordering or > you can reorder them while applying? There are no dependencies between > those patches anyway. Please resend the reordered set when the merge window closes.