Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2743722pxb; Sun, 24 Jan 2021 19:15:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJx1Q6n/RKxLd4ZAOlB0nmUVq77gd3tFOC+MeL1wlpgZm+yXrQwus3peVE3Fw0onJjbkAVBK X-Received: by 2002:a17:906:c40e:: with SMTP id u14mr45991ejz.547.1611544541492; Sun, 24 Jan 2021 19:15:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611544541; cv=none; d=google.com; s=arc-20160816; b=w6jJY+4nGPKClFROAAZjp/qMJG6Ft/pblj5FBi4KA1yn277uSwskiKXyYJjuxhUqc0 +XRUWUKQH0lEhXKqGkhRL+Dn8/9V0mx6a5AZAk/+UOdkTEfAKX30stbsfjV0lYaQbnzQ 4OrqQbh8HDITk7KYqjK+9BpCr+tz5qjZJe/YCNWia2lWCTIODp2ogx1j+d8PBuqNjoEm NGpu6YHvcovGwMt8kTXlUlPxfKczZ0LvyGyth6aAlxoLflkgPIaV7t7gQwp0ojBo1Vfw K4r3dEvkDJMv+Lv5U9zZYqU+4EwLn5YDHFjT7udGsYvpCjUR0QsLe07qPs5MMXhm8Y3K azYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=urJs6HyiGePGW36OxGzHF9HD4lDBm01oVgmZ3FzjjN8=; b=lvVOAnIYMaOt19zfpvV8HVzdZeNgTaeQoOsuy6N4ETQkUbwaVr58jZ+0h6T1miyOOO ilmtaYsjU/hq1h3Yp2qnSPx4xgUoRUP+TOxZ7y05ab5q09OlVcB9YaxpVszZ33JuuVk5 f0A8TLp03NZg434hszmc2wngqFDnDsHW2OSBstqIVzn6brM8Uye2h3h5WT5fmm7K53gN k1abSulPhMpmtJHjvSMHtJlMLWHywziizRlmP9VtbLG/EY8Htxo229YT8QCTH5RsdYfK 7DitAkf/mhngv09w8W7vla4h00dDe6GCPRjELbElB+PUX8ouzmplbz2uVL9EMIBl03F+ OdTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=wq5LV1NS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t17si6910685edc.421.2021.01.24.19.15.17; Sun, 24 Jan 2021 19:15:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=wq5LV1NS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726692AbhAYDN2 (ORCPT + 99 others); Sun, 24 Jan 2021 22:13:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726666AbhAYDNU (ORCPT ); Sun, 24 Jan 2021 22:13:20 -0500 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30D50C061574 for ; Sun, 24 Jan 2021 19:12:34 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id o20so7617577pfu.0 for ; Sun, 24 Jan 2021 19:12:34 -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:in-reply-to:user-agent; bh=urJs6HyiGePGW36OxGzHF9HD4lDBm01oVgmZ3FzjjN8=; b=wq5LV1NSa4zvkXCRKeEch78k1Isx5I3ys5QgrLmB/yKm0wuExPfrByc5l1bnFJ9AWI cY5Y05W+sdINMR/VRK1NCOD2Ltt8ETv68f/DSDHlT7F+4tvk93oGQOeYryVdkIlEqARs fE663ePh32Enyfwm0aIb9HqehH3DWUHokQTEwUDR5qasqDefCvP2FITWE2bLEUMyfJbx xagORdWSP7W3DiJPFdyDCCPatXnigJPX+vphSUA6W1Gh6gWg56rPFOsZRbhnN7AKjy+I uiB7F+Kwh5+4suMxFt11Zo2DdvcNzB0cKXMcoAIFgP4ytL1oM5rk6Zv94N28WLCDYs68 G9MQ== 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:in-reply-to:user-agent; bh=urJs6HyiGePGW36OxGzHF9HD4lDBm01oVgmZ3FzjjN8=; b=HKOgPoKeAo/xBGhZ8SVUfYGtRyRf1NIf4N4IGhh2CLo4gpbAEZAIjhNGCtO1LFpy4t 3fwGdMNp1PueHhEgqzZ7Qgle7scZligyCRVcXcbRLrrqI0QPbz8DaIelE6tfUEQoS2hc mpLZz3TlV7vGWqkugDolrho4sIXFwD2RP/EBDp5m54DSCJp1TK8BW4qJN/TFzHSi6m+O MJPUz93nJebUHC8zgbd5X1M7aFIGP9B9pHIsZTS2GsBofv05/c9gxj18VscdFI0WTq4v i5Ra8MzfSEWgeAKSDXO8mI4T/9gRqkBoYLJEvkZUwlhqFbsgDrA8Tb+IR6HPZKY7H4ne 54rQ== X-Gm-Message-State: AOAM530Iumn63VMld21+Sp5ycJ4r0IbuitjOgw+Jns+tMF9kIA9vdhjQ oHFG0342Q3DPP5O214U0u0WblA== X-Received: by 2002:a65:4542:: with SMTP id x2mr8503202pgr.90.1611544353610; Sun, 24 Jan 2021 19:12:33 -0800 (PST) Received: from localhost ([122.172.59.240]) by smtp.gmail.com with ESMTPSA id e20sm1273051pgr.48.2021.01.24.19.12.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2021 19:12:31 -0800 (PST) Date: Mon, 25 Jan 2021 08:42:29 +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: <20210125031229.adthgnbzlcpt4btj@vireshk-i7> References: <96b57316a2a307a5cc5ff7302b3cd0084123a2ed.1611227342.git.viresh.kumar@linaro.org> <20210122044532.pc7cpcgy3kjbqmls@vireshk-i7> <8af5abe4-fc3f-8ce4-ff14-542754f0275d@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8af5abe4-fc3f-8ce4-ff14-542754f0275d@gmail.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-01-21, 17:31, Dmitry Osipenko wrote: > This may not be true for all kinds of hardware, a display controller is > one example. If display's pixclock is raised before the memory bandwidth > of the display's memory client, then display controller may get a memory > underflow since it won't be able to fetch memory fast enough and it's > not possible to pause data transmission to display panel, hence display > panel may get out of sync and a full hardware reset will be needed in > order to recover. At least this is the case for NVIDIA Tegra SoCs. Hmm, but I expected that the request for more data will only come after the opp-set-rate has finished and not in between. May be I am wrong. There is nothing wrong in doing it the regulator way if required. > I guess it's not a real problem for any of OPP API users right now, but > this is something to keep in mind. Sure, I am not against it. Just that we thought it isn't worth the code. -- viresh