Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp1260273rbb; Mon, 26 Feb 2024 04:09:53 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCW4L4pgSkw6hsFigge/x1M9J3b2wx5yN58qcoKz7/kSfBa9RxpnIjTmcahi2lNr8GrI90VCJ9U9+ox9+wxozBGoRIdDaiFlW96Ewpau2A== X-Google-Smtp-Source: AGHT+IF/BMB78uL1O7soiw9XIHcfFgX42FXH6o4TrZeEmvLxCe4lsljVJJ6KVXJgCvUq0qgAxpaK X-Received: by 2002:a05:6a00:124c:b0:6e5:403a:87c4 with SMTP id u12-20020a056a00124c00b006e5403a87c4mr189102pfi.14.1708949393289; Mon, 26 Feb 2024 04:09:53 -0800 (PST) Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id y25-20020a634959000000b005dbec0a0adfsi3570735pgk.320.2024.02.26.04.09.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 04:09:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-81278-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@collabora.com header.s=mail header.b=06Av+1by; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-81278-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-81278-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=collabora.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 109F4B2B788 for ; Mon, 26 Feb 2024 11:36:45 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A73F82033F; Mon, 26 Feb 2024 11:35:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="06Av+1by" Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B937200BD; Mon, 26 Feb 2024 11:35:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.227.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708947316; cv=none; b=BBf2GpNqqRUm8Nv3vixAsvlKkCQD8jhYHPclXFVIIKwg+rwYWTOpzY8YrIC0seaWM3jc4NcjSeJQlvhHzKXRUTzGua6WPaLumHQw1TUluwvFJF3zo3bcaG9GrFl3MtM8zsdgO/hRUacvUixdau/jsVSyzsXEAodAgQOJz/kJhAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708947316; c=relaxed/simple; bh=PRmRkpP87fdXdGPmJyV15H5s0bYWIoTINv/TZ8U2PQI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hEOLa4KWCILtFfqMZN5Vm+0PDoWxVINjog5ABB1I3YDi2iBGEZMrRKuiTSRx/6Fbnmdtpg40aSOUmfluLtg4Exc1n+0NUQ0lLBch6T5OgTy/FzAl5HghKCGJ1Qgf+qSoFkcFcwC+EyhyHmWQDJEqWpkhmsmhFpNYsNmaSsUsAL8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=06Av+1by; arc=none smtp.client-ip=46.235.227.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1708947313; bh=PRmRkpP87fdXdGPmJyV15H5s0bYWIoTINv/TZ8U2PQI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=06Av+1byeWeu/a9c4RjGq0y+ZA3NMayTQiZwBpfKVYZb79d0czUVUfHmqd+MCssPn cavR8TihvdA8cPiTblZFR6LgjkPtslxjMLIjyub3H9Dpc486cjpvMnQRGhsTpiQpEe EYGdALLBXpwk2eqBtg+YLdOk9vIzQVgZueISZQuy+PmRfd0aw5kY3U8TttgproQtya 0FXw3thFb47JBziyQBvxRbbvzRFOMV4LLHJ07SmmnsR02NrhFjKIpEIdO/b3J1lJo0 HELKfrNWKSzQlMwc5nExdmhANzf2R5hf5f3H9CNr5IZNVixqjc6UNPhBZQI19+tJsa ijE2LkJFaEBeQ== Received: from [100.113.186.2] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 88E6237814B0; Mon, 26 Feb 2024 11:35:12 +0000 (UTC) Message-ID: Date: Mon, 26 Feb 2024 12:35:11 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] clk: mediatek: mt8183: Enable need_runtime_pm on mt8183-mfgcfg Content-Language: en-US To: Chen-Yu Tsai , Pin-yen Lin Cc: Michael Turquette , Stephen Boyd , Matthias Brugger , Weiyi Lu , linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org References: <20240108081834.408403-1-treapking@chromium.org> <20240108081834.408403-2-treapking@chromium.org> From: AngeloGioacchino Del Regno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Il 23/02/24 05:43, Chen-Yu Tsai ha scritto: > On Mon, Jan 8, 2024 at 4:18 PM Pin-yen Lin wrote: >> >> mt8183-mfgcfg has a mutual dependency with genpd during the probing >> stage, so enable need_runtim_pm to prevent a deadlock in the following >> call stack: >> >> CPU0: genpd_lock --> clk_prepare_lock >> genpd_power_off_work_fn() >> genpd_lock() >> generic_pm_domain::power_off() >> clk_unprepare() >> clk_prepare_lock() >> >> CPU1: clk_prepare_lock --> genpd_lock >> clk_register() >> __clk_core_init() >> clk_prepare_lock() >> clk_pm_runtime_get() >> genpd_lock() >> >> Do a runtime PM get at the probe function to make sure clk_register() >> won't acquire the genpd lock. >> >> Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support") >> Signed-off-by: Pin-yen Lin > > Reviewed-by: Chen-Yu Tsai > > Note that this compliments a patch [1] adding the power domain for the mfgcfg > clock controller node, which has been floating around for almost 3 years. > ..but why does this happen *only* on MT8183 and not on any other MediaTek SoC? I understand what you're trying to solve here, but if we explore a bit more, we can maybe come to the conclusion that we don't need to add this flag, and perhaps just enable PM runtime as regular flow for all clock controllers. That would also be cleaner, to some extent. Cheers, Angelo > [1] https://lore.kernel.org/linux-mediatek/20210414073108.3899082-1-ikjn@chromium.org/ > >> --- >> >> (no changes since v1) >> >> drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/clk/mediatek/clk-mt8183-mfgcfg.c b/drivers/clk/mediatek/clk-mt8183-mfgcfg.c >> index ba504e19d420..62d876e150e1 100644 >> --- a/drivers/clk/mediatek/clk-mt8183-mfgcfg.c >> +++ b/drivers/clk/mediatek/clk-mt8183-mfgcfg.c >> @@ -29,6 +29,7 @@ static const struct mtk_gate mfg_clks[] = { >> static const struct mtk_clk_desc mfg_desc = { >> .clks = mfg_clks, >> .num_clks = ARRAY_SIZE(mfg_clks), >> + .need_runtime_pm = true, >> }; >> >> static const struct of_device_id of_match_clk_mt8183_mfg[] = { >> -- >> 2.43.0.472.g3155946c3a-goog >>