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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0217C433F5 for ; Tue, 19 Oct 2021 13:59:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A940161057 for ; Tue, 19 Oct 2021 13:59:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235426AbhJSOB0 (ORCPT ); Tue, 19 Oct 2021 10:01:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232726AbhJSOB0 (ORCPT ); Tue, 19 Oct 2021 10:01:26 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 111B1C061746 for ; Tue, 19 Oct 2021 06:59:13 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id j21so7847470lfe.0 for ; Tue, 19 Oct 2021 06:59:12 -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=ILzjBv7jb2erSvTebu5+BOJoPbprz/SsH8tpTWu6DKY=; b=O2Re71PfoAqOL7WOfHfHJNkIL7iakzqAszzJk8SjFyqWyNb6UHyVMqs6C3OoSWFI9F Xd64Q3XG7+XiEpugc1LBKkCsbt0vFqwjKEg2h5n9zge5VqjQGwXmHsR7/hIdY5oZ9d/g 5DfJKBfi4rxaMhprLEdyPJvfPKfXnn2MFq9VxKNW9P9Y14ABget75hoP0JN+Sd2k3Oz+ NZ3KUgMnI1fTEb+pN3spt4l7LG71Y5Y03w+0lC2USSDgWWWO0H+PGdDB1fo5BV2kHhcj +aX1sr2LryW3yuBIDCwy1jjpcNQSCsz9JM7sylSi9ochWS5bEJdW/sz0oq0atmMOQCsP NEuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ILzjBv7jb2erSvTebu5+BOJoPbprz/SsH8tpTWu6DKY=; b=zB8SSNyvSwCqVilz46sAWHAbUcvurvmrDOysSyXzMZ/mDye3evo5Mq2s8qMr8by3iG VHWARBXtKnWWpSkQikKq1niQDz8uYvnQvUAu71rxFIombixTB7xQsJhgy6nqEtL0u1Yb UlnMI9V4hZ4lsIdwX5C0vGMyQsxb4HIvN66739EbGViBcDdtd57h7p/oPdSlsjRm//i1 3g/HAWl3PFM4bg5pFKXS/FnOFoDeeUqtc2uLXNlORq9XgcKCIG3GfvXi+T2ry4c+jymH hbITl91LOBvqIVowPG9rpoNTg5mdn5G0spiATgCEmZ00IxlrG6bm/6tSaN0fFrn2J215 Hi2A== X-Gm-Message-State: AOAM532N2yRrz5eIiScGbPnCJK1JYgTi82Bagcojiggvw5dH5QZQ3FpT iXqMRSJ5Oy71UciQgEv9TNHcthI0hw22uuyuRyqzXg== X-Google-Smtp-Source: ABdhPJwEZ/12s6FhUn9BwHsNM2h0kgJ1t7fNc7uC9H9v39KVXFWF2Gp6L127iVGYAWoxT0/CCwL8R8bkoNkCTrlDLyE= X-Received: by 2002:a05:6512:3084:: with SMTP id z4mr5900952lfd.167.1634651951419; Tue, 19 Oct 2021 06:59:11 -0700 (PDT) MIME-Version: 1.0 References: <20210517155458.1016707-1-sudeep.holla@arm.com> <20211014145555.uoi2hyoonrptrd5m@bogus> <20211019072425.dvq3ummjdkjmucgm@vireshk-i7> In-Reply-To: <20211019072425.dvq3ummjdkjmucgm@vireshk-i7> From: Ulf Hansson Date: Tue, 19 Oct 2021 15:58:35 +0200 Message-ID: Subject: Re: [PATCH v4] dt-bindings: dvfs: Add support for generic performance domains To: Viresh Kumar , Sudeep Holla Cc: Rob Herring , Linux Kernel Mailing List , DTML , Manivannan Sadhasivam , Hector Yuan , Bjorn Andersson , Rob Herring Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, 19 Oct 2021 at 09:24, Viresh Kumar wrote: > > On 15-10-21, 11:17, Ulf Hansson wrote: > > As far as I understand, the "performance domains" DT bindings that > > $subject patch introduces, allows us to group devices into domains, to > > let them be "performance controlled" together. Right? > > This and it also provides a reg space where we can get/set the > performance state. Right. So that can be done for power-domains too. > > > Unless I am missing something, it looks like power domains DT bindings > > already offer this for us. Yes, certainly, the DT doc [1] needs an > > updated description to better explain this, but other than that we > > should be fine, don't you think? > > I think yes we can make it work through that as well, but I am not > sure if we will be able to use required-opp n stuff here as the DT > doesn't have the OPP table for the CPUs. > > The CPU's freq table is generated at runtime, see > drivers/cpufreq/mediatek-cpufreq-hw.c for example. To me, this looks doable from a genpd provider too. Of course, we may need to extend the genpd interface a bit to make it fit well for this new use case, of course. And I am happy to help, if that is needed. One thing though; how is the aggregation of the OPP votes expected to be done? Is that entirely managed by FW - or is it expected that the cpufreq driver, in this case, keeps track of the aggregated votes too? Don't get me wrong, I am not pushing for these DT bindings to be deprecated (at least not yet :-)), but I would certainly like to understand more about them. In the end, we haven't walked this far, by extending genpd and inventing new DT bindings to enable it to support "performance management" - then just to just forget about them again. :-) Kind regards Uffe