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=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,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 48BD5C388F7 for ; Fri, 13 Nov 2020 14:46:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0EA3421D1A for ; Fri, 13 Nov 2020 14:46:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="oI7Irk60" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726648AbgKMOqX (ORCPT ); Fri, 13 Nov 2020 09:46:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726606AbgKMOqW (ORCPT ); Fri, 13 Nov 2020 09:46:22 -0500 Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A560FC061A4A for ; Fri, 13 Nov 2020 06:46:21 -0800 (PST) Received: by mail-vs1-xe42.google.com with SMTP id l22so5322165vsa.4 for ; Fri, 13 Nov 2020 06:46:21 -0800 (PST) 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:content-transfer-encoding; bh=Aa2pPBMOldZH+yQGH0UrveON65rZ08/cb06MQFHGa0E=; b=oI7Irk60nS8p8IJ9aebTfBT8tKh0VFGTFn4N+jHvPSrvutUGz4HDN9F2eXGWUFLUJO pztkL1zvJJMqmmqAU4axiDuUUDb7ZZEfZv/0TZRBLjwcw3/kbFA/Hx96JgrITvvr02pZ P9ohzUknb4wDMFPoki9mO18MI2KcxcBOr1dFLBdisyT0QQlXZ092Oz52zVXzS4AIl6nm U8S/pCXL5v33Tp7vs3/soInXrThDoA5cbxXaCLXchnNuLPv28h5iBteaaK6ficGI1j82 XTk7m3rfU//IdaFvmbs97w3+GVYDzQv+iWKbaHXieTVM3M0QznSjPWGv6+xYuZCuLvZr 7YfA== 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:content-transfer-encoding; bh=Aa2pPBMOldZH+yQGH0UrveON65rZ08/cb06MQFHGa0E=; b=J17J0q3FtK6oR7snw963/IvFBH8WGdxf2lFeOn2Csdb7yQn/0kUmzEy1h5VjHuMee/ 7y/TcMWJu8OchdCztnMhSrI/9nLRiw/0eMrFmS0RVN4cT/w70wwkDmKSvj8tQBtt6C5p 2sEceRL9wbv599IAVtXCLAAfzuIM1HYIpZHL4RETT+Xrn45Sm2rknGlsfNhv7y3srNwB zPeN6otw7g6vLPHhgg/f9Eo/cgyawBFlf6ddx5Y1/FBE/KTuGqEv2PNV/AP+XC8HfDgO BnSXQOfpl9+bWINc1eTMlNY793Xhxb5JUC5OApPi9ZhXARVnOrMzwsy16NKXPu3Z6QE6 Zv0g== X-Gm-Message-State: AOAM530MRg/MPTB0/89TX1rAXGns78shFImFddMceLGp4J7DlTe623lR i2bCfuPApQ/oIao84RChVGBKCnypnxaL04LyPRGXVg== X-Google-Smtp-Source: ABdhPJwkbgKSdaTWhgIsxWjShz+Kw+ub2606C3A/AwjkR07HCOjuCnqip2AUmLV/UBcfKhNInvgSpQVBCTAIPmGnX5w= X-Received: by 2002:a67:3256:: with SMTP id y83mr1567875vsy.48.1605278780301; Fri, 13 Nov 2020 06:46:20 -0800 (PST) MIME-Version: 1.0 References: <20201104234427.26477-1-digetx@gmail.com> <2716c195-083a-112f-f1e5-2f6b7152a4b5@gmail.com> <1f7e90c4-6134-2e2b-4869-5afbda18ead3@gmail.com> <20201112204358.GA1027187@ulmo> <25942da9-b527-c0aa-5403-53c9cc34ad93@gmail.com> In-Reply-To: <25942da9-b527-c0aa-5403-53c9cc34ad93@gmail.com> From: Ulf Hansson Date: Fri, 13 Nov 2020 15:45:43 +0100 Message-ID: Subject: Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs To: Dmitry Osipenko Cc: Thierry Reding , Viresh Kumar , Jonathan Hunter , Alan Stern , Peter Chen , Mark Brown , Liam Girdwood , Adrian Hunter , Krzysztof Kozlowski , Greg Kroah-Hartman , Lee Jones , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Mauro Carvalho Chehab , Rob Herring , Marek Szyprowski , Peter Geis , Nicolas Chauvet , linux-samsung-soc , driverdevel , Linux USB List , linux-pwm@vger.kernel.org, "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , DTML , dri-devel , Linux Media Mailing List , linux-tegra Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, 12 Nov 2020 at 23:14, Dmitry Osipenko wrote: > > 12.11.2020 23:43, Thierry Reding =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> The difference in comparison to using voltage regulator directly is > >> minimal, basically the core-supply phandle is replaced is replaced wit= h > >> a power-domain phandle in a device tree. > > These new power-domain handles would have to be added to devices that > > potentially already have a power-domain handle, right? Isn't that going > > to cause issues? I vaguely recall that we already have multiple power > > domains for the XUSB controller and we have to jump through extra hoops > > to make that work. > > I modeled the core PD as a parent of the PMC sub-domains, which > presumably is a correct way to represent the domains topology. > > https://gist.github.com/digetx/dfd92c7f7e0aa6cef20403c4298088d7 That could make sense, it seems. Anyway, this made me realize that dev_pm_genpd_set_performance_state(dev) returns -EINVAL, in case the device's genpd doesn't have the ->set_performance_state() assigned. This may not be correct. Instead we should likely consider an empty callback as okay and continue to walk the topology upwards to the parent domain, etc. Just wanted to point this out. I intend to post a patch as soon as I can for this. [...] Kind regards Uffe