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=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 2DEE1C433E0 for ; Fri, 22 Jan 2021 04:46:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E553E238EE for ; Fri, 22 Jan 2021 04:46:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726625AbhAVEqT (ORCPT ); Thu, 21 Jan 2021 23:46:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725854AbhAVEqQ (ORCPT ); Thu, 21 Jan 2021 23:46:16 -0500 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5815EC06174A for ; Thu, 21 Jan 2021 20:45:36 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id s15so2522946plr.9 for ; Thu, 21 Jan 2021 20:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=bbM2dKaYpv41IbTKFCnMXIDb9vPr8F5wpZdCakgIuw0=; b=uHQ/LNKv9Ii50fZb5s/RYG98hKXnhSwPVs+L5cPkfIj6K5CZebreMfP5nc4Gb/6QJ5 en/0A+D/wVkrU/v1I1mZ4ey4n9lTklU45zI9HBM+ZIxlO0gsG7kePmQj5M4dQt2+8mcS tdi5E804YOrjQzv9HV5b1auk/Vnnp4oxbpk5DFl1MEHdy0OGHxTArUDvzPPcMDID5Wql JDs6C5dsNRPyxQobVu8AspBDMQYCFaaMEIug/AVM2NjHzwlhxuX2RThA5DN5fB7Z56Hy hqdulwE2KMuLCX8fb9+42VUWneZI4v8PzuMnwbIsOjA5OMtxuZL29KrqU5stPKnzJNvq ustA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=bbM2dKaYpv41IbTKFCnMXIDb9vPr8F5wpZdCakgIuw0=; b=kqf1btm7lNtC4qsm1fe9l/lfJ8EAK2SUrFhewJh6+2Y0HT7J6nHEnwZvTuUvtKqDlI 2uXWIIHJE0GGhq8nxrQzEYrwGxZQrpm044tRulwcvTGOdXWsZrugr4lkwxJnlaID2aup TR78+JPeke3fm/DlsIkIbTeQktWmNKPLds/IL3fyW/neSg6UsozZ9X8HHiSNJjpJw2rs VzHBMzIlIvlZDOv6cmjAuE8FT2u7cuBkaIrIOSD4a5dZ8XkxvO4bUUq85RX1H04u9sTI 2YNJa0xV+By4fR7h8Gp8n/l6XR8W7z5xk2L3/96klKUL/lhUN7uPkAAvWVTaUhcIP4ds aLFQ== X-Gm-Message-State: AOAM530aVdcuuR5ZZUnaFF/lR56DO0auxF2Ml7pO/MubtDSc7rn8shWw GiIza46A9i3AmSNAg5+BEvH86g== X-Google-Smtp-Source: ABdhPJykjY//oEpUUCa97mb5wm8LARwb1qXlD4yQTn+cDtixVvBIM0+Lr3O+f+FTqokTzkG4IHsSZg== X-Received: by 2002:a17:90a:4598:: with SMTP id v24mr3128802pjg.135.1611290735797; Thu, 21 Jan 2021 20:45:35 -0800 (PST) Received: from localhost ([122.172.59.240]) by smtp.gmail.com with ESMTPSA id n128sm7428126pga.55.2021.01.21.20.45.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jan 2021 20:45:34 -0800 (PST) Date: Fri, 22 Jan 2021 10:15:32 +0530 From: Viresh Kumar To: Dmitry Osipenko Cc: Viresh Kumar , Nishanth Menon , Stephen Boyd , linux-pm@vger.kernel.org, Vincent Guittot , Rafael Wysocki , Sibi Sankar , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 03/13] opp: Keep track of currently programmed OPP Message-ID: <20210122044532.pc7cpcgy3kjbqmls@vireshk-i7> References: <96b57316a2a307a5cc5ff7302b3cd0084123a2ed.1611227342.git.viresh.kumar@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-01-21, 00:41, Dmitry Osipenko wrote: > 21.01.2021 14:17, Viresh Kumar пишет: > > @@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq) > > > > if (!ret) { > > ret = _set_opp_bw(opp_table, opp, dev, false); > > - if (!ret) > > + if (!ret) { > > opp_table->enabled = true; > > + dev_pm_opp_put(old_opp); > > + > > + /* Make sure current_opp doesn't get freed */ > > + dev_pm_opp_get(opp); > > + opp_table->current_opp = opp; > > + } > > } > > I'm a bit surprised that _set_opp_bw() isn't used similarly to > _set_opp_voltage() in _generic_set_opp_regulator(). > > I'd expect the BW requirement to be raised before the clock rate goes UP. I remember discussing that earlier when this stuff came in, and this I believe is the reason for that. We need to scale regulators before/after frequency because when we increase the frequency a regulator may _not_ be providing enough power to sustain that (even for a short while) and this may have undesired effects on the hardware and so it is important to prevent that malfunction. In case of bandwidth such issues will not happen (AFAIK) and doing it just once is normally enough. It is just about allowing more data to be transmitted, and won't make the hardware behave badly. -- viresh