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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 8171FC47082 for ; Tue, 8 Jun 2021 14:39:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 614D961078 for ; Tue, 8 Jun 2021 14:39:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233481AbhFHOli (ORCPT ); Tue, 8 Jun 2021 10:41:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233478AbhFHOlg (ORCPT ); Tue, 8 Jun 2021 10:41:36 -0400 Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 505D1C061574 for ; Tue, 8 Jun 2021 07:39:42 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id d13so206327vkl.10 for ; Tue, 08 Jun 2021 07:39:42 -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=u9JL6GQBrbia5ZUKjbw1dPoYLRps1kdBbTif5jsryJ0=; b=jllCO/Oy8PYSQ3Asp/fe59Ithm6VaXNkW9IAlpj87+vwQTDPOXcKNWR2G8AJuRWxbv vhU7lfM8EmkEV9Rp6q2dBxdPlqwJiN4HPhBLZNdVd3yBREfjRUKL1oLy7TS5CKXQ8AvJ by4gLGiYR9XJAJ9DhhWTztfCCKlOaQriBO8zzaoQ79NM+ULaa2gA4f12ogsM9yNG+zsh w6sUCuN05zJaRpEz08adFBUACHr5Gy1IPkW1fDshK6Vc49Q7fP/dxsJVKOqtJa95LAVN EhXxkGd7ahI09xQfqRdKk5HmdLkfBlhCooSaqHlfk91R3c0vLBNiflx84oPtt/tqd6d9 mhsw== 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=u9JL6GQBrbia5ZUKjbw1dPoYLRps1kdBbTif5jsryJ0=; b=ccYqsfyai7f+ZZXDZX++FeTnVEjxemrRprjDwO7k8yRcRTgb5bJTkDGeZNTBRAX/0J QQbs9G3m03NiBzvIympX0HjKlGbcJDqcnDs44hf4Vi2AthvdkSlu9o+bpO8LiHkkGqgu wO54xEPD04gt9QKX8dbxzGPwSVM1WHBIPjp6PzaThv8pz3Ic4Nf89yllJWLVuXWL9nmD Ne34u4onNvczZ8MZihv2wwJO7UO//vwQ9bS24rjdwjpFlJR3/t1RNkQIYo5DJ8W/nqiD vTlzjn4X5C+S/1NXL5AKbW7mvN2Iy5Oopt4ebTJM3OK5/z0p0E9dGm9u/t/nMahE+7yL EWkw== X-Gm-Message-State: AOAM532NXNzrN2Hqm0fMj/zp4whqFE4hxaeN2ejbW87iDu908vsBqYGl QSUMaks89Ii1kNU9oNnlmg6VGfPN1Q6PbVxwCFSujA== X-Google-Smtp-Source: ABdhPJycWh+LxfYgKSTARsn0up26wJdWuTT+FZiXXVdYBc2xqimAfmf8I1zNbp3q2gT1Jy7SxgAa93VQC7VzP0ZOEg4= X-Received: by 2002:a1f:4ec1:: with SMTP id c184mr260560vkb.8.1623163180279; Tue, 08 Jun 2021 07:39:40 -0700 (PDT) MIME-Version: 1.0 References: <20210603093438.138705-1-ulf.hansson@linaro.org> <20210603093438.138705-5-ulf.hansson@linaro.org> <20210608142019.GG4200@sirena.org.uk> In-Reply-To: <20210608142019.GG4200@sirena.org.uk> From: Ulf Hansson Date: Tue, 8 Jun 2021 16:39:03 +0200 Message-ID: Subject: Re: [PATCH v2 4/4] PM: domains: Drop/restore performance state votes for devices at system PM To: Mark Brown Cc: Stephan Gerhold , "Rafael J . Wysocki" , Viresh Kumar , Dmitry Baryshkov , Linux PM , Dmitry Osipenko , Jonathan Hunter , Thierry Reding , Roja Rani Yarubandi , Bjorn Andersson , Vincent Guittot , Stephen Boyd , Linux Kernel Mailing List , Rajendra Nayak Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Tue, 8 Jun 2021 at 16:20, Mark Brown wrote: > > On Tue, Jun 08, 2021 at 04:08:55PM +0200, Ulf Hansson wrote: > > > Honestly, I am not sure about what the regulator-fixed-domain intends > > to model, but I assume it's something that fits well to be modelled as > > a plain regulator, to start with. > > > Perhaps Mark can chime in and spread some light over this? > > IIRC it's for situations where there's a device that's normally built as > a separate chip that got built into a bigger SoC and wants to rear end > something onto a power domain, I guess especially if the power domain > doesn't cover the whole of a Linux device. Alright, thanks for explaining! Certainly something that should not be mixed up with a regular power rail for shared resources (aka power-domain). Maybe it's worth trying to extend the description in the DT binding a bit, so it doesn't get abused? Kind regards Uffe