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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51334C433EF for ; Sat, 2 Oct 2021 20:44:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3A81361B06 for ; Sat, 2 Oct 2021 20:44:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234030AbhJBUqh (ORCPT ); Sat, 2 Oct 2021 16:46:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233975AbhJBUqg (ORCPT ); Sat, 2 Oct 2021 16:46:36 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 357FBC061714; Sat, 2 Oct 2021 13:44:50 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id j5so48530857lfg.8; Sat, 02 Oct 2021 13:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=T5NA95fXjewFVQZ7RXmQGjvZaYL3KLG4ILjTuHYXm9E=; b=VInxURP7xctDXfL0Dl1Z5iIuI8Z57STPldPnyJ+NEoakoMviQJJZLMTDvRJajSYeUA L6hAx+33fXvlxHQdSLAb2swwYgCSXcm4IHTOs4QNGPXy0n+3kc1PaSRsPOeccYBdBeZd i/GVKW6ch0QjgR5Al9izKnsKjtkLP9b6WFxxbgQj5xOtMJ+SSJ3vI3nxrqadHVRi/RnA W6QxtWyfIbdShJzgMDhIpqfX5qzkmNQXHlvgGM11cFUopWEMKunpWxyqUcwKJKYvFAG5 +vztm6uVxmXOzcI8Wt5yVr3CSoQmJa2Le0PpZjwLrPdDyp4eM6GhDyuSByQAckD1zOgW c3ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=T5NA95fXjewFVQZ7RXmQGjvZaYL3KLG4ILjTuHYXm9E=; b=o+AkgwIXTGmhQJOReVcp/TKkZzv7PXYcfMekTaitKUtIJwq9Jx49Ek3A6rzLNWnGDw P14BK/n3ooXkpVEH9nCyL8FXZYN7ZEwDQcX/HwTKjBIRyMgJudlk3iv1sfciLtZTSdOR vwOpvOwVQIenigGsvIM5EuTWq+4BDfs+q6YQF1gWnaCKscYOjk/MGgW3xBNn8ZhUdVCZ 7xYmRwRBj20i5ZIDmJzuKM5BziIPaasu+aA7E2ExtPF5uOYuwbOaw7T/wguPP+RgSZQ4 IMKvmtAHcPJB8dSJI9T5/DLw2qkb2FpwIt50gSksOXa8MP0ZwlDi4BPe4g+NLYlyBgjd yb5A== X-Gm-Message-State: AOAM5320QoRG2UTT3/F5jVU3Ku5BPR/cGcwERvAogi3KnHxkjgIS1xsP utURybmrqidGKVMJdilKdqs= X-Google-Smtp-Source: ABdhPJzClEAya5hcn4TqFZQoHIn0mpgv86q3zG4rhbGd/Hwr0saEHFeEJIpz6XM0cCQNRVK631z4Mw== X-Received: by 2002:a2e:80cd:: with SMTP id r13mr5454584ljg.415.1633207488462; Sat, 02 Oct 2021 13:44:48 -0700 (PDT) Received: from [192.168.2.145] (94-29-52-238.dynamic.spd-mgts.ru. [94.29.52.238]) by smtp.googlemail.com with ESMTPSA id v27sm1233535lfp.0.2021.10.02.13.44.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Oct 2021 13:44:47 -0700 (PDT) Subject: Re: [PATCH v13 06/35] clk: tegra: Support runtime PM and power domain To: Ulf Hansson Cc: Thierry Reding , Jonathan Hunter , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Mikko Perttunen , Peter Chen , Lee Jones , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , Nishanth Menon , Adrian Hunter , Michael Turquette , Linux Kernel Mailing List , linux-tegra , Linux PM , Linux USB List , linux-staging@lists.linux.dev, linux-pwm@vger.kernel.org, linux-mmc , dri-devel , DTML , linux-clk , Mark Brown , Vignesh Raghavendra , Richard Weinberger , Miquel Raynal , Lucas Stach , Stefan Agner , Mauro Carvalho Chehab , David Heidelberg References: <20210926224058.1252-1-digetx@gmail.com> <20210926224058.1252-7-digetx@gmail.com> From: Dmitry Osipenko Message-ID: <24101cd6-d3f5-1e74-db39-145ecd30418b@gmail.com> Date: Sat, 2 Oct 2021 23:44:46 +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 01.10.2021 15:32, Ulf Hansson пишет: >> +static __maybe_unused int tegra_clock_pm_suspend(struct device *dev) >> +{ >> + struct tegra_clk_device *clk_dev = dev_get_drvdata(dev); >> + >> + /* >> + * Power management of the clock is entangled with the Tegra PMC >> + * GENPD because PMC driver enables/disables clocks for toggling >> + * of the PD's on/off state. >> + * >> + * The PMC GENPD is resumed in NOIRQ phase, before RPM of the clocks >> + * becomes available, hence PMC can't use clocks at the early resume >> + * phase if RPM is involved. For example when 3d clock is enabled, >> + * it may enable the parent PLL clock that needs to be RPM-resumed. >> + * >> + * Secondly, the PLL clocks may be enabled by the low level suspend >> + * code, so we need to assume that PLL is in enabled state during >> + * suspend. >> + * >> + * We will keep PLLs and system clock resumed during suspend time. >> + * All PLLs on all SoCs are low power and system clock is always-on, >> + * so practically not much is changed here. >> + */ >> + >> + return clk_prepare(clk_dev->hw->clk); > I am trying to understand, more exactly, what you intend to achieve > with the clk_prepare() here. It looks a bit weird, to me. Can you try > to elaborate a bit more on the use case? The Tegra GENPD driver enable/disable clocks when domain is turned on. This can't be done during early system resume, when domains are getting turned on by the drivers core, because when clock is enabled, it's getting prepared (RPM-resumed) and this preparation fails because performance state of the clock goes up and it doesn't work during the early resume time since I2C, which applies the state to hardware, is suspended and can't work at that early time. Secondly, Tegra has arch-specific low level assembly which touches clocks during last phase of system suspend and in the beginning of resume. Hence, clocks should stay prepared during suspend just because technically clock should be prepared before it can be enabled. > Is this rather about making sure that the clock's corresponding PM > domain stays powered on during system suspend? In that case, I think > there may be an alternative option.... > This is not about domain staying powered on, this is about keeping the performance state of the domain high during suspend.