[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0e92e72d610bd97963b686366c5334d2.sboyd@kernel.org>
Date: Wed, 10 Apr 2024 20:48:45 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Matthias Brugger <matthias.bgg@...il.com>, Michael Turquette <mturquette@...libre.com>, Pin-yen Lin <treapking@...omium.org>
Cc: Chen-Yu Tsai <wenst@...omium.org>, linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org, Pin-yen Lin <treapking@...omium.org>, Weiyi Lu <weiyi.lu@...iatek.com>, linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org, Bosi Zhang <u201911157@...t.edu.cn>, Nicolas Boichat <drinkcat@...omium.org>, Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH v4] clk: mediatek: Do a runtime PM get on controllers during probe
Quoting Pin-yen Lin (2024-03-12 04:51:55)
> mt8183-mfgcfg has a mutual dependency with genpd during the probing
> stage, which leads to 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. Instead of only modifying mt8183-mfgcfg,
> do this on all mediatek clock controller probings because we don't
> believe this would cause any regression.
>
> Verified on MT8183 and MT8192 Chromebooks.
>
> Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support")
> Signed-off-by: Pin-yen Lin <treapking@...omium.org>
>
> ---
Applied to clk-fixes
Powered by blists - more mailing lists