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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 09B60C4338F for ; Thu, 12 Aug 2021 16:24:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E543A60C40 for ; Thu, 12 Aug 2021 16:24:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232340AbhHLQZA (ORCPT ); Thu, 12 Aug 2021 12:25:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbhHLQY6 (ORCPT ); Thu, 12 Aug 2021 12:24:58 -0400 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27C6DC061756; Thu, 12 Aug 2021 09:24:33 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id c24so14433345lfi.11; Thu, 12 Aug 2021 09:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JfjRt23sWV2lqaXvpl990G0yCZxuQFU1QAX/YZyxnf0=; b=CLGQBJ7UF455CW+Q2Heb9qGA4ngD1epBzx33MmovxhQspf/Nr3LGBgPa09ZmzZtUKN 3tdTlC442x6ciRdxrSb0sEScPF1RDJlgJS8Yy/+bNttWoH1+Ke447jc0s3seV1gm4ZT+ IvY8BaLBQrpB/8LD2kp9G2pGd3EGf9hXm27UebF7UKADlvICNymv3mjWP9qT0jqtzs86 bkvQ4XoWNvq1rwDSVkudNhWvvLVhiMidOtgVx0xpp53E9q99c7WOMy5rIJDlpmsOLXQ4 r3nF0g8qu1XLNci6/r/SCQA/FJCk2O4KwF8CeUop5jKwqmyIMBK9wM7tbtkTf9U/GY8Y L9gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JfjRt23sWV2lqaXvpl990G0yCZxuQFU1QAX/YZyxnf0=; b=tLqxGgs94cbD+5JlOtfFVlLEq4nLebsvNleGRkb4dzfspXpPedRNCS2ZXDvJu4FgGU BWgfaoMPouVXda5WsZCf3CL3wxcWEtDLHDIqyLHz0FhzPMaF/mYkOBNPUpjZb32FWz7+ 89qRdqPGyqXse7X0orNJcJ32nzdEW7e0ILNCiGPEzDVr3snC4VEsQZAhsibYP9tDFJ40 cLIfoJlodcIg4xvBY/eabaE4MHrziWOCVFOWGy0DMlJP0wHgqvTcpMNUltU0GyDEwV50 CY4FgoB7xRkfKQhnAt+bBWJADQDyfvwqJkUn3LD9wHn5Ia3HMfb938rn5o36D9iZIKmJ goJA== X-Gm-Message-State: AOAM5323425vsk24StdeLIQ0LMPxqc0w3torRTzOgFgBFVP5HZLmZ98K LK6SzZgTEdlI6CQwrZ5TE2gINr5v5o8= X-Google-Smtp-Source: ABdhPJzQaIt36WqBlaQ8sP9BP1GtVdRtFl+PsuIi3z5BlibHuKasVw/o8VDojoMjBkkUqMP3Fn7tEw== X-Received: by 2002:a19:e002:: with SMTP id x2mr3092401lfg.84.1628785471402; Thu, 12 Aug 2021 09:24:31 -0700 (PDT) Received: from [192.168.2.145] (46-138-117-53.dynamic.spd-mgts.ru. [46.138.117.53]) by smtp.googlemail.com with ESMTPSA id e7sm384080ljq.9.2021.08.12.09.24.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Aug 2021 09:24:30 -0700 (PDT) Subject: Re: [PATCH v7 02/37] soc/tegra: pmc: Implement attach_dev() of power domain drivers To: Ulf Hansson Cc: Thierry Reding , Jonathan Hunter , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Linux Kernel Mailing List , linux-tegra , Linux PM References: <20210701232728.23591-1-digetx@gmail.com> <20210701232728.23591-3-digetx@gmail.com> <1034458d-78e0-5036-e278-6fee5d0d75ac@gmail.com> <6741262b-386b-7635-fd42-ebd4f877fddd@gmail.com> <8e110e08-1268-464c-6edb-0a3f640d43d6@gmail.com> From: Dmitry Osipenko Message-ID: Date: Thu, 12 Aug 2021 19:24:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 12.08.2021 14:17, Ulf Hansson пишет: > On Thu, 12 Aug 2021 at 03:40, Dmitry Osipenko wrote: >> >> 12.08.2021 01:41, Dmitry Osipenko пишет: >>>>> I am not saying you should change the clock rate. The current code >>>>> path that runs via devm_tegra_core_dev_init_opp_table() just calls >>>>> clk_get_rate and then dev_pm_opp_set_rate() with the current rate to >>>>> vote for the corresponding OPP level. Right? >>>>> >>>>> Isn't this exactly what you want? No? >>>> I see now what you meant, it's actually a simpler variant and it works >>>> too. Thank you for the suggestion, I'll prepare v8. >>>> >>> My bad, it doesn't work at all. I actually need to use the rpm_pstate or >>> something else because performance state is coupled with the enable >>> state of the device. If device is never rpm-suspended by consumer >>> driver, then the initialized performance state is never dropped. Hence I >>> want to initialize the state which is set only when device is resumed. >>> >>> I'll need to think more about it. >> >> GENPD core has these false assumptions: >> >> 1. It assumes that by default all devices are at zero performance level >> at a boot time. This is not true for Tegra because hardware is >> pre-initialized independently from GENPD. > > Right, which is similar to other SoCs. > >> >> 2. It assumes that nothing depends on performance level and devices can >> operate at any level at any time. Not true for Tegra and other platforms >> where performance level is coupled with clocks state of attached >> devices. OPP framework glues clock and performance level together for >> us, which works good so far. > > Right, OPPs need to be managed differently depending on the SoC. > That's why genpd is there to help and to model this as "performance > states" and to allow operations to be set through SoC specific > callabacks, for example. > > More importantly, the assumption is that in general, consumer drivers > should use the OPP library to vote/set OPP levels, they shouldn't call > dev_pm_genpd_set_performance_state() - unless they know exactly what > they are doing. > >> >> Hence I either need to patch every driver to use dev_pm_opp_set_rate in >> order to sync clk rate with the perf level at device runtime, or I need >> to preset the rpm perf level to allow GENPD core to set the level before >> device is resumed. > > When the device is getting attached to its genpd (during the probe > sequence and for a single PM domain case), runtime PM is disabled for > the device. If you would call dev_pm_opp_set_rate() from a genpd > callback during attach (without changing the rate), this means you > would update/synchronize the vote. In this way, the vote is set before > the device is runtime resumed by the driver, right? I was doing that previously, but then realized that for some devices the state needs to be synced only once device is rpm-resumed. Making RPM driver to perform the syncing worked well. > On the other hand, patching the driver should also be quite simple and > you need to do that anyways, don't you? It will be extra boilerplate code in the drivers, but perhaps it's the best option for today, I'll consider it for v8. Thank you for helping with the review.