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 8C5ACC4338F for ; Wed, 4 Aug 2021 10:00:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F72561004 for ; Wed, 4 Aug 2021 10:00:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237325AbhHDKA3 (ORCPT ); Wed, 4 Aug 2021 06:00:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237310AbhHDKAX (ORCPT ); Wed, 4 Aug 2021 06:00:23 -0400 Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C72EC061799 for ; Wed, 4 Aug 2021 03:00:11 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id n22so690460vsq.11 for ; Wed, 04 Aug 2021 03:00:11 -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:content-transfer-encoding; bh=KZQURuUvCTt1Dtzvc06E1K1bLOJD8iseyaRl8XN5Pfc=; b=hLsLtCjOZNf8KRF5d/vdQ9oZuNAoT9Eg3LqcwzTR1WqqPznTHVqfZ7QC5CE4teJJOE vJROdJstvA+WA5mLYhAzMDB1DIxd5ywVPl9xMCFBIh1nUiTgw4Ph+dkj8D9SzUXKA6fZ sVa8WeDimt4VpSJ8VnXxHAmqb8yztQWS7mn+vpYKF1rfotJmVW8TYetCigqq/FVr7uNx 531UgugUZQaVtyfqyl9eLDl7+/Lms+2Cc9uwWWjTqJfI79kJFFB8mZjP069zbQcQniDe 1bMS/4FMCNWGqUH1zGD6cnkYxxDtYopR7XSSzLLSqOsWrvu8ZUZz5EusoKUKcEpo00ps 0LAg== 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=KZQURuUvCTt1Dtzvc06E1K1bLOJD8iseyaRl8XN5Pfc=; b=Xm+IioyKLNm67FaK/yTqCy6/ZhwP+qaIflMvEgwVRiSYHyNsRgvTbDA8IL8F7YoZl3 Mh/+jIG2xlXQmp/fs/oorGJE+NNfUPkOsJzjR+Ov8HL1IxwYelbb83ioDm9sSaII3z7T 9QL9RMUNPd7Qm7OH4YTotPGZLjx7wr0roWGCjbC84XaENNu34dcTG5zxDM/pvpvT75eg eXDrFiA/CvrhR+Vr3zsxNX5t2c/PQQcXKt8uW887z6MaJnac5Qq0RqYGKHTcMqoRigt/ lQHtHb1m9NHZcIqs3o9ngaKhERPDj9Oq7+w/zHYPzwyn3OMNxtjHC+dsgL08PAhBi1hg +X2g== X-Gm-Message-State: AOAM531GAXJcX/4cWC/gxQqk0YKbC17aVilEHQzWiD1F6px7CMGyvbdR CxwiRj0fJTlpaGQLHCvBkl9OgVUjbkXTflYdJ5eZfQ== X-Google-Smtp-Source: ABdhPJxbm5Y/wyGvHg385WeEq/rdxsg9pBpHshQlE18FxBQCwqaKoec7NnZjlIGraYbQyO4/D4SyyrqC1cHImBk2U4o= X-Received: by 2002:a67:328f:: with SMTP id y137mr16927749vsy.34.1628071210155; Wed, 04 Aug 2021 03:00:10 -0700 (PDT) MIME-Version: 1.0 References: <20210701232728.23591-1-digetx@gmail.com> <20210701232728.23591-3-digetx@gmail.com> <1034458d-78e0-5036-e278-6fee5d0d75ac@gmail.com> In-Reply-To: <1034458d-78e0-5036-e278-6fee5d0d75ac@gmail.com> From: Ulf Hansson Date: Wed, 4 Aug 2021 11:59:33 +0200 Message-ID: Subject: Re: [PATCH v7 02/37] soc/tegra: pmc: Implement attach_dev() of power domain drivers To: Dmitry Osipenko Cc: Thierry Reding , Jonathan Hunter , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Linux Kernel Mailing List , linux-tegra , Linux PM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2 Aug 2021 at 20:23, Dmitry Osipenko wrote: > > 02.08.2021 17:48, Ulf Hansson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > ... > >> + if (!list_empty(&genpd->child_links)) { > >> + link =3D list_first_entry(&genpd->child_links, struct = gpd_link, > >> + child_node); > >> + core_genpd =3D link->parent; > >> + } else { > >> + core_genpd =3D genpd; > >> + } > > > > This looks a bit odd to me. A genpd provider shouldn't need to walk > > these links as these are considered internals to genpd. Normally this > > needs lockings, etc. > > > > Why exactly do you need this? > > We have a chain of PMC domain -> core domain, both domains are created > and liked together by this PMC driver. Devices are attached to either > PMC domain or to core domain. PMC domain doesn't handle the performance > changes, performance requests go down to the core domain. Did I get this right? The core domain is the parent to the PMC domain? > > This is needed in order to translate the device's OPP into performance > state of the core domain, based on the domain to which device is attached= . So, the PMC domain doesn't have an OPP table associated with it, but some of its attached devices may still have available OPPs, which should be managed through the parent domain (core domain). Correct? Is there a DT patch in the series that I can look at that shows how this is encoded? Hmm, I have the feeling that we should try to manage in some generic way in genpd, rather than having to deal with it here. > > >> + > >> + pd_opp_table =3D dev_pm_opp_get_opp_table(&core_genpd->dev); > >> + if (IS_ERR(pd_opp_table)) { > >> + dev_err(&genpd->dev, "failed to get OPP table of %s: %= pe\n", > >> + dev_name(&core_genpd->dev), pd_opp_table); > >> + ret =3D PTR_ERR(pd_opp_table); > >> + goto put_dev_opp; > >> + } > >> + > >> + pd_opp =3D dev_pm_opp_xlate_required_opp(opp_table, pd_opp_tab= le, opp); > >> + if (IS_ERR(pd_opp)) { > >> + dev_err(&genpd->dev, > >> + "failed to xlate required OPP for %luHz of %s:= %pe\n", > >> + rate, dev_name(dev), pd_opp); > >> + ret =3D PTR_ERR(pd_opp); > >> + goto put_pd_opp_table; > >> + } > >> + > >> + /* > >> + * The initialized state will be applied by GENPD core on the = first > >> + * RPM-resume of the device. This means that drivers don't ne= ed to > >> + * explicitly initialize performance state. > >> + */ > >> + state =3D pm_genpd_opp_to_performance_state(&core_genpd->dev, = pd_opp); > >> + gpd_data->rpm_pstate =3D state; > > > > Could the above be replaced with Rajendra's suggestion [1], which > > changes genpd to internally during attach, to set a default > > performance state when there is a "required-opp" specified in the > > device node? > > It's not a "static" performance level here, but any level depending on > h/w state left from bootloader and etc. The performance level > corresponds to the voltage of the core domain, hence we need to > initialize the voltage vote before device is resumed. Why not let the driver deal with this instead? It should be able to probe its device, no matter what state the bootloader has put the device into. To me, it sounds like a call to dev_pm_genpd_set_performance_state() (perhaps via dev_pm_opp_set_opp() or dev_pm_opp_set_rate()) from the driver itself, should be sufficient? I understand that it means the domain may change the OPP during boot, without respecting a vote for a device that has not been probed yet. But is there a problem with this? Kind regards Uffe